Web Performance Optimization: mejora el tiempo de carga de tu web

Comparte en tus redes...

Como ya sabemos todos a estas alturas, una parte muy importante en el posicionamiento de páginas web es la optimización OnPage de nuestro sitio, y dentro de esta optimización, el factor más relevante, puede ser la tiempo de carga de una web o rendimiento de la página. La optimización del rendimiento de la web, también denominado WPO por sus iniciales en inglés (Web Performance Optimization), consiste en usar todas la posibilidades que se nos ofrece, para acelerar la carga de nuestra web y contentar a Google, que en este sentido, es bastante insistente.  De hecho ya muchos habrán oído hablar del Page Speed de Google, una herramienta para identificar las formas de acelerar tu web y hacerla “amigable” para con los móviles (es decir, responsiva).

WPO

 

Todas las pruebas en este ejemplo, van a ir dirigidas sobre un nuevo sitio en el que estoy trabajando y tratando de levantar, www.trasterosur.es. Es una empresa malagueña de alquiler de trasteros y parkings para motocicletas, que trata de hacerse hueco en el mercado de la ciudad.

Entramos en la URL de Page Speed de Google e introducimos la dirección de la página, el resultado es el listado que vemos arribe, con la nota y las posibilidades de mejora para tu web. En este caso tenemos en velocidad un 67 sobre 100, que si bien no está nada mal, puede mejorarse mucho.

Los factores a mejorar según Page Speed son:

  • Habilitar compresión
  • Especificar caché de navegador

Hay otras menos importantes como :

  • Eliminar el Javascript que bloquea la visualización
  • Minificar CSS, HTML y Jacascript

Por otro lado tenemos la experiencia del usuario para móviles, o responsividad, que en este caso es casi perfecta, 98 sobre 100. ¡Ni tocarla!

Web Responsiva

Vamos a ver todos los pasos que debemos dar para solucionar estos puntos, y otros tantos que pueden tocarse, hasta optimizar al máximo la velocidad de carga de nuestra  web y tratar de arañar esos puntos al Page Speed de Google, que lógicamente serán tenidos en cuenta por el buscador a la hora de posicionarnos en las SERPs para una búsqueda determinada. Vamos a basarnos en el ejemplo real de la web de la empresa Trastero Sur, y vamos a ir comprobando como efectivamente vamos mejorando la web… como siempre decimos: el movimiento se demuestran andando.

 

Elección del Servidor (Hosting)

Tener un buen servidor es mucho más importante de lo que se cree, aunque la mayoría aún opta por un servidor barato de pésima calidad. Yo he descubierto este año para varios cliente nuevos, empresas de hosting sacadas de un guión de película de terror mala, pero que no comentaré por motivos obvios.

Mi recomendación es hacer un pequeño estudio de mercado, que no te llevará más de unos minutos, y utilizar un par de servidores de hosting cuyos comentarios sean buenos. Tu propia experiencia será el mejor aliado a la hora de decidirte definitivamente por tu hosting de cabecera.

Reducir el número de peticiones HTTP

Cada vez que se carga un elemento de  la web, tu navegador hace una petición al servidor donde se alojan las páginas. La idea es disminuir el número de peticiones que hay que hacer para visualizar la web ¿Cómo? Pues la respuesta en obvia… reduciendo el número de elementos a descargar. Pero como los elementos son los que son, lo que tendremos que hacer es combinar todo lo que podamos para reducir el número de descargas.

Por ejemplo, si tenemos varios ficheros CSS o Javascript, podemos combinarlos en uno solo y disminuir el número de peticiones. Otra opción es usar las imágenes en Sprites a la hora de usar iconos, es decir, varios iconos insertados en el mismo fichero de imagen.

Yo no soy partidario de usar esta técnica, porque me gusta tener bien estructurados los ficheros CSS y JS, y prefiero sacrificar estos milisegundos. Además en el caso que nos atañe, solo tenemos dos archivos con hojas de estilo, por lo que el cambio sería imperceptible. Los dejamos como está.

 

Utililizar compresión de datos en el servidor con GZIP y DEFLATE

GZIP comprime datos antes de enviarlos al navegador desde el servidor y es muy fácil de configurar, siendo soportado en la mayoría de los casos. Determinados archivos como imágenes y vídeos, no merece siquiera la pena comprimirlos con esta técnica, pero todo el contenido que sea texto conviene comprimirlo antes de descargarlo al navegador.

En servidores Apache, la opción de compresión se activa en el fichero .htaccess añadiendo estas líneas:

# Compresión  de ficheros  #
AddOutputFilterByType DEFLATE text/xml
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE text/plain
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/html5
AddOutputFilterByType DEFLATE text/txt
AddOutputFilterByType DEFLATE text/pdf
AddOutputFilterByType DEFLATE application/javascript
AddOutputFilterByType DEFLATE application/x-javascript
AddOutputFilterByType DEFLATE application/xml
AddOutputFilterByType DEFLATE application/xhtml+xml
AddOutputFilterByType DEFLATE application/rss+xml
AddOutputFilterByType DEFLATE application/x-httpd-php
AddOutputFilterByType DEFLATE application/x-httpd-fastphp
AddOutputFilterByType DEFLATE image/svg+xml

El fichero .htaccess, como cualquier otro fichero con datos y acciones, es recomendable comentarlo, para no perderte en el futuro interpretando qué demonios hacía la línea tal. En este ejemplo comprimimos todos los tipos de ficheros que puedan contener texto: xml, css, html, txt, pdf,

 

Especificar la Caché del Navegador

Este punto, al igual que el anterior, siempre aparece en el análisis de SpeedPage de Google como factor importante a tener en cuenta. Una página tiene cientos de componentes: imágenes,  hojas de estilo, scripts, etc.  y cada vez que un usuario accede a nuestro sitio, tiene que descargar este contenido completamente. Sin embargo aquí tenemos una opción muy poderosa para disminuir el tiempo de carga de la web: podemos decirle al servidor qué tipo de archivos debe descargar y qué tipo de archivos no deben descargarse en el caso de que el usuario ya lo haya hecho en el pasado.  El tiempo de carga se reducirá enormemente.

Suponemos que un internauta, visita varias veces nuestro sitio en una semana para recabar información. Está claro que la primera vez que entra tiene que descargar todo el contenido de la web, pero las sucesivas veces que acceda, al permanecer toda la información en su caché, podemos evitar la descarga del contenido especificándole al servidor que no descargue determinado tipo de material hasta que no pase más de una semana, por ejemplo.

El problema que podemos encontrar aquí es que si definimos un tiempo de expiración de las imágenes de una semana, pero a diario estamos cambiando las fotos de portada (mantenimiento el mismo nombre), el usuario que repita visita, verá siempre la misma imagen ya eliminada. Por eso es muy importante definir el tiempo de expiración de cada tipo de fichero correctamente.

# BEGIN Expire headers
<ifModule mod_expires.c>
 ExpiresActive On
 ExpiresDefault "access plus 5 seconds"
 ExpiresByType image/x-icon "access plus 2592000 seconds"
 ExpiresByType image/jpeg "access plus 2592000 seconds"
 ExpiresByType image/png "access plus 2592000 seconds"
 ExpiresByType image/gif "access plus 2592000 seconds"
 ExpiresByType application/x-shockwave-flash "access plus 2592000 seconds"
 ExpiresByType text/css "access plus 604800 seconds"
 ExpiresByType text/pdf "access plus 604800 seconds"
 ExpiresByType text/javascript "access plus 216000 seconds"
 ExpiresByType application/javascript "access plus 216000 seconds"
 ExpiresByType application/x-javascript "access plus 216000 seconds"
 ExpiresByType text/html "access plus 600 seconds"
 ExpiresByType application/xhtml+xml "access plus 600 seconds"
</ifModule>
# END Expire headers
# BEGIN Cache-Control Headers
<ifModule mod_headers.c>
 <filesMatch "\.(ico|jpe?g|png|gif|swf)$">
 Header set Cache-Control "public"
 </filesMatch>
 <filesMatch "\.(css)$">
 Header set Cache-Control "public"
 </filesMatch>
 <filesMatch "\.(js)$">
 Header set Cache-Control "private"
 </filesMatch>
 <filesMatch "\.(x?html?|php)$">
 Header set Cache-Control "private, must-revalidate"
 #Debe ser comprobada cada vez
 </filesMatch>
</ifModule>
# END Cache-Control Headers

 

Con las estas instrucciones estamos indicando al navegador del cliente que “cachee” o guarde los contenidos estáticos (imágenes) durante 30 días, los contenidos de texto  durante 7 días, los scripts durante unos 3 días y el contenido dinámico (html) durante 10 minutos. Todos los tiempos se expresan en segundos..

Recuerda que si la página web está en modo de desarrollo o actualización, deberás desactivar la caché para apreciar los cambios.

 

función flush();

Esta función permite limpiar el buffer de datos. Es recomendable usarla (siempre que usemos ficheros .PHP), justo después de la cabecera (</head>), para que el servidor disponga de memoria para procesar el restos de scripts de la página.

En página realizadas con WordPress, entraríamos en Apariencia -> Edición, y el código lo insertaríamos en el archivo header.php del tema activo, con la siguiente línea:

 <?php flush(); ?>

 

Chequear los enlaces rotos

Hacer peticiones de descarga sobre ficheros que no existen aumenta una barbaridad el tiempo de carga de la web, por eso debemos siempre evitar a toda costa los enlaces a archivos que no existen: imágenes, vídeos, css, etc. Al principio de la vida de una web, esto es raro que ocurra, pero cuando va  pasando el tiempo siempre se eliminan ficheros, que puede provocar este error (error 404).

Una herramienta para descubrir los enlaces rotos es Screaming Frog, que puedes descargar con una licencia total desde este enlace.

 03ScreamingFrog
Vemos marcado en amarillo que todos los enlaces responden bien, devolviendo un código 200. ¡¡Pues adelante!!


Evita las redirecciones

No será la primera vez que leo artículos de reputados a afamados SEO que te explican las diferentes formas de redireccionar  páginas en tu web: redirección 301, meta refresh, etc. pero esto sólo debe hacerse por causas de fuerza mayor. Una redirección es una duplicidad en la solicitud y lógicamente esto puede demorar la carga varios milisegundos importantísimos.

 

Domain Sharding y CDN (Red de distribución de contenidos)

Estas técnicas se me antojan demasiado sofisticadas, pero como existen, vamos a comentarlas. La idea es repartir los contenidos (scripts y CSS) alojándolos en diferentes ubicaciones: diferentes subdominios en el primer caso y diferentes centros de datos (servidores) en el segundo. El límite de conexiones por subdominio es de 3 ó 4, por lo que haciendo esto evitamos colas de descargas en los contenidos estáticos; de otra forma, cuando se empiecen a descargar los scripts y CSS y se llegue a 4 descargas, se producirá un retraso.

Los CDN son servicios externos bastante caros, por lo que sólo se recomienda su uso para webs con mucho tráfico y proyección internacional.

 

 

Llegados a este punto, ya hemos realizado una serie de mejoras en la web, por lo que podemos medir de nuevo la velocidad, a ver si estamos en el buen camino.

02movil-opt

¿Cómo? ¿81 sobre 100? Pues parece que la cosa marcha, ¿eh? Realizando sólo unos pocos cambios en el fichero .htaccess y poco más, hemos reducido el tiempo de carga de la web en un 15%. Pero no se vayan todavía, aún hay más… Nos vemos en el siguiente post. La siguiente imagen es el test para ordenador, mucho mejor.

04pc

 

Leave a comment