Contenido

8 maneras de ahorrar ancho de banda con tu RSS

12 jul

+ 2

En Digg, he encontrado este artículo que nos indica 8 pasos para ahorrar ancho de banda solo modificando nuestro RSS. Y esto es algo que debido a que las lecturas por RSS están aumentando a medida que los usuarios se dan cuenta de las ventajas que este sistema ofrece, frente a ir a las páginas a leer directamente.

No conozco la especificación de RSS, pero creo que voy a tener que echale un vistazo.

1.  Usa el tag ttl

 El Tag ttl se introduce diractamente dentro del tag channel en tu RSS, y como sus iniciales indican, se trata de una abreviatura de Time To Live e indica el tiempo en número de minutos que el lector de noticias debe esperar para volver a leer el feed.

De esta forma podemos hacer que por ejemplo nos relea cada 180 minutos en vez de cada 60 min que es tiempo por defecto sinó se informa el tag.

<ttl>180</ttl>

2. Usa el tag skipDays

Otra forma de ahorrarnos recargas innecesarias sería haciendo que los lectores de feeds omitan tu feed unos días determinados, imaginemos que los fines de semana somos de los que no tocan el PC para nada más que poner música, entonces el feed puede permitirse el lujo de pegarse todo el fin de semana sin que se actualize.

skipDays tambien va a la altura del tag channel.

<skipDays>
  <day>Saturday</day>
  <day>Sunday</day>
</skipDays

3. Usa el tag skipHours

Incluso, podriamos hacer que nuestro rss evitara que fuera leido a ciertas horas del día, por ejemplo por la noche no hace falta que se recarguen ya que generalmente estamos durmiendo…(mi rio solo xDD).

skypHours al igual que el anterior (y el otro) van dentro del tag channel.

<skipHours>
  <hour>7</hour>
  <hour>8</hour>
</skipDays>

4. Añadir la cabera If-Modified-Since.

Muchos lectores de RSS y clientes envian la cabecera If-Modified-Since en su petición a tu RSS. Esta es una de las maneras que tienen los clientes de hacer una petición condicional, y tu RSS devuelve una cabecera 304 Not Modified en caso de no estar modificado y por su opuesto en caso de modificación, enviaremos una cabecera 200 OK si el contenido es nuevo.

Por defecto WordPress se encarga de gestionar este punto, así que los usuarios que lo usen, ya tienen un trabajo menos :D

5. Añadir las cabeceras HTTP ETag y If-None-Match

El ETag (entity tag) es una respuesta HTTP para diferenciar dos o más elementos en la misma URL. Se suele usar para cachear contenido por los navegadores y de esta forma ahorrar ancho de banda. Para ello debemos generar un entity tag único, como por ejemplo un MD5 del contenido del RSS, de esta forma el cliente solo encontrará un entity tag diferente cada vez que cambies el contenido de tu rss. En caso de no haber cambios enviaremos automáticamente el estado 304 Not Modified.

6. No envies el contenido para las peticiones HEAD

Las peticiones head, son identicas al GET y no debemos devolver mensajes en el cuerpor de la respuesta. La meta información contenida en la cabecera HTTP en la respues de un head debería ser idéntica a la información enviada en la respuesta de un petición GET. Este método puede ser usado para obtener metainformación acerca de la entidad empleada por la petición sin transferir nada de contenido.

Por este motivo para este tipo de peticiones, podemos ahorrarnos unos cuantos bytes más.

7. Limita el número de elementos publicados

Evidentemente el número de posts en el rss hará que este sea más ligero y por consiguiente más benevolo con el ancho de banda.

8. Publica contenidos parciales.

Pese a los problemas que le encuentro a este punto, ya que soy partidario de ofrecer el contenido completo a los usuarios y no tener que obligarlos a seguir leyendo en la página, es cierto que esto al igual que el punto anterior, ayudan a reducir la cantidad de datos a enviar en nuestro rss.

Personalmente prefiero sacrificar un poco de ancho de banda para que los usuarios puedan leer el contenido completo.

  • A mi con el olor ya me conoce ….
    ffmmfmf
    ABRAZO VIRTUAL

  • La mejor forma de ahorrar ancho de banda es poniendo la feeds en FeedBurner, hay un pluging que te redirecciona desde wordpress a esas feeds, y el ancho banda que se encargue google de optimizarlo, cada dia estoy mas convencido que los desarrollos largos y costosos en la red no tienen futuro, lo mejor aprovechar los servicios y el codigo libre para desarrollar a mayor velocidad y con el minimo de quebraderos de cabeza, para poder centrarse en el contenido que es la sustancia, el armazón/programación ha de ser modular, escalable y de desarrollo rápido.

    Un saludo

Comentar

#

Me reservo el derecho de eliminar y/o modificar los comentarios que contengan lenguaje inapropiado, spam u otras conductas no apropiadas en una comunidad civilizada. Si tu comentario no aparece, puede ser que akismet lo haya capturado, cada día lo reviso y lo coloco en su lugar. Siento las molestias.