0

Manual de buenas prácticas para mejorar la velocidad de un sitio web: el servidor

Buena PracticaRegla de oro: el 80 – 90% del tiempo de respuesta es motivado por la descarga de componentes de la página: imágenes, scripts, Flash, CSS, etc…

Aquí propongo siete buenas prácticas que podemos aplicar en nuestros servidores web (no sólo en IHS) para optimizar la carga de un sitio web que tengamos alojado en él.

1.- Usar una CDN (Content Delivery Network).

La cercanía del usuario a nuestro servidor impacta en los tiempos de respuesta. Desplegar el contenido por varios servidores dispersos geográficamente hará que nuestra página más rápida para el usuario.

Una CDN es una colección de servidores dispersos por el mundo para mejorar la descarga de contenido de un sitio web. El servidor seleccionado para servir el contenido a un determinado usuario normalmente viene determinado por parámetros como el mnor número de saltos de red o un tiempo de respuesta más rápido, entre otros.

2.- Usar Expires Header.

El uso de Expires Header reduce significativamente las peticiones HTTP de un sitio, pues su función es convertir los elementos de la página en cacheables.

Aunque su uso principal se da con las imágenes, son aplicacbles a todos los elementos: scripts, Flash, etc… Los navegadores y los proxies usan la caché para reducir el número y el tamaño de las peticiones http. Con Expire Headers le decimos al navegador cliente el tiempo por el que un componente será cacheado y evitaremos su carga hasta la fecha indicada.

Hay que tener en cuenta que si usamos tiempos muy elevados habrá que modificar el nombre del componente (versionando, por ejemplo: imagen_2_0_2.jpg) cada vez que lo actualicemos, pues si mantenemos el nombre no será descargado por el navegador cliente.

Apache e IHS tienen la directiva ExpiresDefault, que nos permite establecer un valor pord efecto para esos expires.

 3.- Comprimir los componentes con Gzip.

La compresión reduce el tiempo de transmisión de las peticiones http al reducir el tamaño. El navegador notifica al servidor que acepta compresión mediante un header en la request:

Accept-Encoding: gzip, deflate

El servidor comprime la respuesta usando el método indicado y lo notifica en el header:

Content-Encoding: gzip

La compresión reduce el tamaño de la respuesta http del orden de un 70%. Se calcula que el 90% de los navegadores aceptan compresión.

Muchos sitios comprimen sus documentos html, pero descuidan sus scripts y hojas de estilo. Las imágenes y documentos del tipo pdf no se deben comprimir (porque ya lo están) y hacerlo en documentos tipo xml o json puede ser contraproducente, ya que pueden aumentar su tamaño. Además, el proceso de compresión usa demasiada CPU para el resultado tan pobre que se obtiene.

4.- Configurar ETags.

Las Entity Tags son un mecanismo por el cual los servidores y navegadores web determinan cuando el elemento cacheado en el navegador coincide con el del servidor. Son básicamente strings de texto entrecomillado que identifican inequívocamente una versión de un componente.

Ejemplo: Si un servidor envía

HTTP/1.1 200 OK
Last-Modified: Tue, 12 Dec 2011 03:03:59 GMT
ETag: “10c24bc-4ab-457e1c1f”
Content-Length: 12195

El navegador lo valida devolviendo el código

GET /i/emetreinta.gif HTTP/1.1
Host: us.yimg.com
If-Modified-Since: Tue, 12 Dec 2011 03:03:59 GMT
If-None-Match: “10c24bc-4ab-457e1c1f”
HTTP/1.1 304 Not Modified

Si el ETag coincide, se devuelve un código 304 y se ahorran 12195 bytes.

El problema que tienen las ETags es que suelen ser específicas a un servidor específico, por lo que sitios web que se sirven desde un entorno clusterizado tendrán complicaciones para manejar las peticiones http correctamente, pues muchas ETags no coincidirán y recibiran un código 200 en lugar de un interesante 304.

En estos casos en concreto es mejor evitar el uso de ETags y trabajar con otro modelo de validación: el Last-Modified.

5.- Renovar el buffer al principio.

Una petición nueva conlleva de 200 a 500 ms hasta que se forma la respuesta html. Durante este tiempo, el navegador está ocupado esperando por la respuesta del servidor. En php existe la función flush(), que permite enviar el código html parcialmente para que el navegador lo vaya formando mientras el servidor continúa procesando la petición.

Un lugar bueno para colocar la función flush es justo debajo del head de la página.

6.- Usar GET en las peticiones AJAX.

Si usamos XMLhttpRequest podemos comprobar que el método POST está implementado en los navegadores como un proceso formado por dos pasos: primero se envían los encabezados y luego el resto de datos. En cambio, GET usa un único paso. El único problema es que GET está limitado a 2K de longitud de URL.

7.- Evitar imágenes con sources vacíos.

Cuando una imagen tiene el atributo src vacío, ya sea en código html o JavaScript, provoca una nueva petición http.

Esto es especialmente malo en casos de sitios web con tráfico elevado, pues se genera un montón de tráfico inesperado y se pierden ciclos de CPU en procesos que no sirven para nada. Otra consecuencia grave es que el servidor haya enviado una cookie, esta haya sido aceptada y la página no se pueda mostrar debido a esta imagen sin src, pues afectará a las próximas visitas que se hagan a dicha página en concreto.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *