Tutorial WPO: Optimizando el Front-end II
En la anterior entrega del tutorial expliqué qué es el front-end y cómo analizarlo. Conocimos varias herramientas y vimos un caso práctico sobre el uso de una de ellas: GTMetrix.
Plan de vuelo:
- WPO: ¿Qué es y por qué utilizarlo?
- Optimizando el Front-end I
- Optimizando el Front-end II
- Optimizando el Front-end III
En esta ocasión voy a comenzar a explicar cómo optimizar el Front-end. Si bien no todas las partes, algunas de ellas.
Ya avancé en el anterior punto del tutorial algunas de las cosas que optimizaremos, pero ahora vamos a verlas una por una.
Reducir el número de peticiones HTTP
Cada vez que nuestro sitio web carga un fichero está realizando una petición HTTP. Son peticiones cada imagen, fichero CSS, fichero javascript…
Si conseguimos reducir estas peticiones, veremos una mejora (considerable) en el tiempo de carga de nuestro sitio web. A menos peticiones menos tiempo tarda la carga del sitio.
¿Por qué debemos colocar el CSS en la cabecera y el js en el pié?
La respuesta es sencilla: CSS se encarga de dar la apariencia (el diseño) a nuestra página web y, en caso de estar corrupto o mal en cuanto a sintaxis, no obstruye (tanto) la carga.
Por otro lado, Javascript sí obstruye la carga. Esto significa que cuando la página se comienza a descargar, la descarga en paralelo de estos elementos hace que se puedan bloquear otros y, nuevamente, el tiempo de carga del sitio se puede ver altamente afectado.
Normalmente los ficheros CSS, por norma, deberían incluirse en la cabecera <head> (da estilos a nuestra página) y los JS en el pié de página (justo antes de la etiqueta de cierre </body>, aunque da efectos y funcionalidades a la página, no es imprescindible para la visibilidad de la página).
Esto, aunque no reduce el número de peticiones HTTP, es importante para optimizar el tiempo de carga.
Combinando ficheros CSS y JS
En un sitio web creado con un gestor de contenidos podemos tener alrededor de 4 ficheros css (el propio del gestor de contenidos, el propio del tema y alguno extra de plugins o añadidos). Esto supone 4 peticiones HTTP con sus respectivas paradas (en muchas ocasiones el navegador espera a terminar una petición para procesar la siguiente); lo que supone una pérdida de tiempo significante.
Esto sumado a que con los ficheros javascript pasa tres cuartos de lo mismo (librería jquery, función main del tema, plugins jquery para sliders y demás) estamos malgastando recursos del servidor y, obviamente, ralentizando el tiempo de carga de la web.
Si conseguimos combinar todos estos ficheros en uno sólo (obviamente un sólo CSS y un sólo JS) estaremos pasando de, por ejemplo, seis ficheros javascript y cuatro css a un único javascript y un CSS.
Combinar imágenes e iconos en Sprites CSS
Los sprites CSS son imágenes grandes que contienen todas las imágenes que forman parte del diseño de la web.
Si el concepto te parece retorcido, quizá esta lectura te ayude a comprender mejor qué son y cómo se utilizan los sprites CSS, ya que esta entrada no pretende explicar este concepto.
Al reducir el número de imágenes a descargar, estamos rebajando el número de peticiones HTTP, una vez más.
Aunque hay más técnicas para reducir el número de peticiones HTTP, las considero demasiado «avanzadas» para este tutorial de introducción al WPO.
Paralelizar peticiones HTTP
Ahora que hemos reducido el número de peticiones HTTP, es hora de paralelizar su descarga.
Pero antes, ¿qué significa eso de ‘paralelizar’?
El protocolo que nos permite el intercambio de información, generalmente HTTP, limita a los navegadores web en cierta medida.
Sería de locos pensar que un navegador web es capaz de descargar 100 cosas simultáneamente; más cuando nuestras conexiones colapsarían.
Los navegadores, en la actualidad, son capaces de paralelizar peticiones HTTP; llegando a realizar entre 2 y 5 peticiones simultáneas al servidor web (y este, a su vez, es capaz de contestarlas).
Si jugamos con este concepto metido en la cabeza, jugaremos con ventaja.
El tamaño sí importa
A un navegador web, que es una máquina, no le importa cuántas peticiones le hagas realizar. Pero, nosotros que jugamos con la ventaja de saber que es capaz de realizar de dos a cinco peticiones simultáneas, vamos a enviarle peticiones más grandes pero en menor cantidad.
Es decir, no es lo mismo realizar 100 peticiones de 2KB cada una que 2 peticiones de 100KB, ¿verdad?
Esto nos lleva al punto que comentaba antes de combinar CSS y JS en un sólo fichero; ¿Para qué decirle al navegador que descargue dieciséis ficheros pudiendo decirle que descargue sólo dos?
¿Por qué debemos colocar el CSS en la cabecera y el js en el pié? (y 2)
Aunque dicen que las segundas partes nunca fueron buenas, en este caso creo que será al contrario.
Ahora ya tenemos en la cabeza el concepto de paralelización que realizan los navegadores y sabemos cómo funciona, lo que nos permitirá entender mejor el por qué los ficheros CSS han de ir en la cabecera y los JS en el pié.
Aparte de lo ya mencionado anteriormente, los CSS implican que el navegador ha de recolocar el contenido donde la hoja de estilos le diga, por esto, si le indicamos desde un principio dónde ha de hacerlo evitaremos efectos extraños de repintado en la página.
Al indicarlo en la cabecera del documento garantizamos que el navegador descargará el CSS al tiempo que el HTML, colocando los elementos HTML en su sitio desde el primer momento.
Con Javascript pasa algo curioso y es que, normalmente, los navegadores no paralelizan más de dos ficheros javascript al tiempo, lo que da lugar a una obstrucción en el tiempo de carga.
Si aplazamos su llamada para el final del proceso de carga conseguiremos que, aunque éstos bloqueen la carga del sitio, el sitio web ya se esté visualizando correctamente.
Evitar enlaces a contenidos con errores 404
Un error 404, lo mires por donde lo mires, es malo. Si en el proceso de carga de nuestro sitio web hacemos una llamada a un fichero que no existe, el navegador intentará solicitarlo y el servidor, a su vez, intentará servirlo sin éxito. Esto hará que el navegador malgaste el tiempo.
En próximas entregas, analizaré más elementos del front-end y explicaré cómo mejorar los tiempos de respuesta del servidor.
Si te gusta esta entrada, agradécelo en los comentarios. La gratitud da ganas de escribir y esforzarse más.
También se agradece que lo compartas en las redes sociales.
Mira el resto del tutorial:
Capítulo anterior: Tutorial WPO: Optimizando el Front-end I
Capítulo siguiente: Tutorial WPO: Optimizando el Front-end III
hola, muy buena la información, y se agradece el contenido que explica bien algunos conceptos.
Gracias por tu tiempo y tu esfuerzo