1. Identifica las páginas con excesivos RTR.
La minimización de los RTR comienza con la concienciación. Muchas páginas tendrán más de 100 RTR por página cuando en realidad hay que esforzarse por conseguir menos de 50. A menudo, los desarrolladores o los profesionales del SEO que miran todas las solicitudes de una página encontrarán que algunos de los elementos solicitados faltan (404) y nadie lo ha notado. Aunque falten, el navegador tarda en hacer la petición y volver con las manos vacías, por lo que estas páginas deberían eliminarse o arreglarse inmediatamente.
También debes arreglar los activos que se han movido y devuelven una respuesta 301 o 302. Estas respuestas significan que el navegador tuvo que ir a un lugar, luego seguir otro conjunto de instrucciones para ir a otro lugar para obtener el activo, pero cada nueva ubicación necesita más tiempo. Es como ir a una tienda de comestibles solo para que te digan que no tienen lo que necesitas, pero que puedes conseguirlo en otra tienda más adelante. Y lo que es aún peor: si hay una cadena de redirecciones, es como ir a la segunda tienda de comestibles para descubrir que también han dejado de tener el artículo y ahora hay que probar en una tercera.
2. Combinar archivos siempre que sea posible.
El siguiente paso para un sitio web optimizado es combinar archivos (como JavaScript y CSS) siempre que sea posible. Por ejemplo, si una página utiliza 10 hojas de estilo (archivos CSS) que podrían combinarse todas en una, deberías hacerlo. Del mismo modo, si utilizas varios archivos JavaScript que podrían combinarse en uno solo, hazlo también. Trata de pensar en las cosas a nivel del sitio y de la plantilla. Deberías tener un archivo JavaScript para todo el sitio para el JavaScript que está en cada página del sitio y un archivo JavaScript específico para cada plantilla de página en el sitio. Lo mismo puede hacerse con el CSS. Asegurarse de que estos archivos también se referencian siempre con el mismo nombre de archivo y la misma ubicación también ayudará a que se almacenen en la caché correctamente.
3. Optimizar el orden de renderización.
Después de eliminar y consolidar para disminuir el número total de RTR, lo siguiente que se puede hacer es ajustar el orden en que se solicitan las cosas para hacerlo más rápido. De la misma manera que hay pasos que deben completarse en una receta antes de que puedan comenzar otros pasos, hay un cierto orden que un navegador móvil seguirá y que debe ser respetado al construir una página. Siguiendo con el ejemplo de la tienda de comestibles, si tu receta requiere que algo se marine durante 2 días, es importante conseguir primero los elementos necesarios para el adobo, de modo que puedas comenzar mientras adquieres el resto de los ingredientes y no después.
Trasladando esta analogía al mundo de la web, el adobo es como un bloqueador de render, porque nada más puede ocurrir en el proceso de cocción hasta que esté hecho. Solo puedes prepararte para los siguientes pasos del proceso de cocción obteniendo los ingredientes mientras las cosas se marinan. Esto es como el renderizado de ruta crítica, en el que se priorizan los elementos críticos, como la etiqueta head, el contenido de la página y el diseño básico de la página primero, y se retrasan los elementos que son menos críticos, especialmente si van a retrasar la carga de los elementos más críticos. Esto puede mejorar drásticamente la experiencia de carga para los usuarios y darles la confianza de que el resto de la página se cargará rápidamente. También les da activos para empezar a evaluar mientras se produce el proceso de carga.
4. Crea una estrategia de carga de la página.
Dado que los motores de búsqueda emulan a los usuarios humanos, experimentan las páginas de forma muy similar a la tuya. Lo mejor que puedes hacer para ordenar las solicitudes de velocidad es saber qué es lo más importante para la experiencia del usuario y del bot en los primeros segundos que están en la página. Esto es generalmente la información en la etiqueta de la cabeza y el texto y las imágenes en la página. Por lo general, la gente tarda unos segundos en interactuar con cualquier cosa del sitio, por lo que la mayor parte del JavaScript no necesita cargarse al principio. En su lugar, las representaciones visuales del JavaScript, como casillas o expansores adicionales, pueden cargarse como marcadores de posición antes de que el JavaScript sea necesario. El JavaScript es especialmente lento y engorroso de cargar. Para garantizar que la carga de JavaScript no ralentice tanto la experiencia que los usuarios y los bots se queden mirando una página en blanco durante mucho tiempo, lo ideal es cargar algo para que los usuarios miren y luego cargar el JavaScript en segundo plano, mientras los usuarios miran la página.
Después de JavaScript, los vídeos y las imágenes son lo siguiente que más tarda en cargarse. Los vídeos y las imágenes que están en la parte baja de la página no deben entorpecer la experiencia en la parte superior de la página, donde los usuarios y los bots suelen empezar. Este concepto, de retrasar la carga del contenido que no es visible, se llama "lazy-loading". El lazy-loading puede lograrse de varias maneras (diferido, asíncrono y con la etiqueta meta de lazy-loading de Google).
La mejor herramienta para encontrar oportunidades para las imágenes de carga perezosa es Google PageSpeed Insights. Para optimizar las imágenes, también puedes utilizar la etiqueta de imagen Lazy-load de Google, pero hasta ahora solo se respeta en los navegadores móviles y de escritorio Chrome (aunque podría ampliarse en el futuro). Con cualquiera de los dos métodos, debes utilizar la herramienta de inspección de URL en Google Search Console para verificar que los elementos que realizan una carga lazy-load son visibles en el renderizado de la página de la herramienta y en el HTML renderizado.
5. Comprime todo lo que puedas.
Después de minimizar y priorizar el RTR para cada plantilla de página, deberías comprimir lo que puedas. La compresión ayuda a aumentar la velocidad de la página al ahorrar ancho de banda. La compresión Gzip es una forma de comprimir archivos y puede ser configurada en la mayoría de los servidores, pero hay otras opciones disponibles. También se puede someter la mayor parte del código a un proceso de minificación que reduce el tamaño del archivo final de transferencia. Sin embargo, es difícil comprimir imágenes mediante estos métodos. Puedes utilizar la página de revisión del rendimiento en WebPageTest.org para encontrar la lista de comprobación de optimización completa, que muestra todos los activos de la página, si están comprimidos con gzip y su nivel de compresión.
Para la compresión de imágenes, en lugar de comprimirlas y minimizarlas, es importante que el diseñador las entregue al desarrollador en el formato más comprimido posible, reduciendo los archivos de imagen. Esencialmente, tienen que hacer que el tamaño del archivo final sea lo más pequeño posible sin comprometer la apariencia de la imagen. Por lo general, las fotos deben guardarse como archivos JPG y los iconos e ilustraciones deben guardarse como archivos GIF. Para que las imágenes de gran tamaño se vean bien en los ordenadores de pantalla completa, sin que se atasquen las diminutas pantallas de los móviles, considera la posibilidad de utilizar el protocolo de imágenes responsivas o de utilizar un servidor de imágenes como el de Fastly para enviar dinámicamente una versión preescalada de la imagen a las pantallas más pequeñas.
6. Almacenar en caché las páginas adecuadas en el momento adecuado.
El siguiente paso es ayudar a los navegadores y a los bots a identificar lo que se puede reutilizar y lo que debe obtenerse de nuevo cada vez con el almacenamiento en caché del navegador, una funcionalidad que puede configurarse de diferentes maneras, una de ellas a través de las redes de entrega de contenidos o CDN, por sus siglas en inglés. La mayoría de los elementos de un sitio, especialmente los que no cambian más de una vez a la semana o comparten información en tiempo real, como las noticias, el tiempo o los resultados deportivos, pueden almacenar en caché la mayor parte de los elementos de sus páginas hasta un año. El almacenamiento en caché significa que cuando los usuarios visitan una página, los navegadores buscan localmente en su memoria para ver si ya tienen un archivo que se necesita para construir una página. Esto ahorra las peticiones de ida y vuelta, y mejora el tiempo de carga. Los bots de los motores de búsqueda siempre ven una página como si nunca la hubieran visto antes, por lo que no utilizan el almacenamiento en caché activo, pero pueden percibir cuando el almacenamiento en caché está en marcha y pueden utilizarlo para estimar el tiempo de carga de una página.
Lo importante es entender que el almacenamiento en caché se basa en los nombres de los archivos y su ubicación en el servidor. Por lo tanto, si utilizas un archivo en muchas páginas, como un logotipo, siempre haz referencia a él con el mismo nombre de archivo y URL, incluso si existe en varios lugares en tu servidor. Esto puede usarse en tu beneficio porque significa que solo tienes que actualizar el nombre de archivo de un elemento y su referencia en el HTML para obtener una nueva versión del elemento en la caché. Así, por ejemplo, si haces un ajuste a tu logo, simplemente cambiando el nombre del archivo de 'logo' a 'logov2', hará que la nueva versión se almacene en la caché y la antigua se olvide. De esta manera, cuando permites que algo se almacene en caché durante un año, no estás diciendo que no vas a cambiar el elemento durante el año, sino que si lo haces, harás referencia al elemento actualizado o nuevo con un nuevo nombre de archivo.
Las opciones de la caché pueden ser un poco complicadas, así que lo mejor es pensar en ellas como si fuera un alimento que puede caducar. Algunos alimentos caducan más rápido que otros, por lo que debes hacer saber al navegador qué cosas se estropean y hay que tirarlas rápidamente, y cuáles pueden permanecer en la estantería durante un tiempo de forma segura, sin necesidad de reemplazarlas. Puedes utilizar una herramienta como WebPageTest.org para ayudarte a entender dónde están las oportunidades. Lo importante es entender que aquí no se establece una caducidad ni una edad máxima para que el elemento exista en la caché. Por lo tanto, el navegador simplemente asumirá que debe ser recuperado cada vez, ya que el almacenamiento en caché del navegador no puede ocurrir a menos que se especifiquen estos detalles.
Dado que las opciones de la caché indican al navegador cuándo un elemento es demasiado antiguo para ser utilizado, a veces se le denomina "tiempo de vida de la caché" o "tiempo de vida de la frescura". Si algo está más allá de su vida útil de frescura o de caché, se debe completar el viaje de ida y vuelta al servidor para obtener una versión fresca. Si los artículos aparecen como "caducados", significa que han superado su vida útil de frescura y, tanto en la analogía de la tienda de comestibles como en la del navegador, deben ser reemplazados la próxima vez que se necesiten.
Del mismo modo que no es útil tener las estanterías llenas de comestibles caducados, no es útil tener una caché llena de contenido web caducado. A la inversa, también es ineficiente tirar comestibles (archivos) que todavía son perfectamente utilizables. Cuando asignes tiempos de caché a tus archivos, es útil pensar en esto y también considerar las consecuencias de ser generoso con el tiempo de caché. Si haces un cambio menor en su logotipo, no será el fin del mundo si el antiguo logotipo se sigue mostrando, puedes mantener esa vida de caché larga, especialmente si planeas ser diligente con la actualización de los nombres de los archivos cuando hagas cambios. Con nombres de archivo diferentes, no hay preocupación de que se muestre el logotipo antiguo.
7. Construir páginas móviles aceleradas (AMP, por sus siglas en inglés).
Todo esto puede parecer complicado y por eso Google creó una solución más sencilla para la optimización de la velocidad de las páginas. Las páginas móviles aceleradas, o AMP, son un subconjunto de HTML que sigue unas directrices mucho más estrictas sobre lo que se puede incluir. El objetivo es conseguir que la mayoría de las páginas tengan un tiempo de carga de 1 segundo en el móvil, lo que generalmente se consigue. AMP permite a Google tomar el control de la mayor parte de las cosas difíciles al almacenar en caché y configurar el proceso de carga y la mayoría de los elementos descritos anteriormente para que esté lo más optimizado posible.
En algunos casos, las empresas crean nuevas páginas AMP y las enlazan desde las páginas existentes en el sitio desde la etiqueta head. Esto indica a Google que debe servir la página AMP cuando la persona que la solicita se encuentra en un dispositivo móvil o con una conexión lenta. En otros casos, puedes sustituir sus páginas existentes (o sus páginas móviles existentes, si tienen sitios separados) por páginas AMP. Esto se denomina “Canonical AMP” o “AMP canonical”. Google prefiere este método porque las páginas AMP son extremadamente fáciles de rastrear, procesar, indexar y clasificar para Google. Sin embargo, es posible que las empresas no lo prefieran, ya que las limitaciones y los requisitos de AMP pueden hacer que las páginas sean un poco escuetas. El AMP también puede complicar o limitar algunos de los seguimientos y pruebas que se pueden hacer en las páginas de escritorio, por lo que esta es otra razón por la que algunas personas lo evitan.
Los sitios que cuentan con AMP válido siguen todas las reglas y directrices de AMP y, a su vez, Google muestra un pequeño rayo gris con ellos en los resultados para móviles. Es más probable que Google los incluya en carruseles especiales de resultados que tienden a posicionarse en la parte superior de una página. Esto está muy bien, pero si ser válido para AMP va a causar demasiados problemas a tu sitio web, está bien utilizar el código AMP sin ser válido para AMP. Deberías utilizar AMP HTML cuando puedas, sin preocuparte de seguir todas las reglas. Seguirás beneficiándote de la velocidad de AMP HTML y AMP JavaScript, lo que no está nada mal teniendo en cuenta que es gratis. Recuerda que la velocidad tiene un impacto directo en la interacción y la conversión, pero probablemente también ayuda con la profundidad de rastreo y otros aspectos de la eficiencia del rastreo.
Los navegadores móviles funcionan de forma diferente a los navegadores de escritorio. También tienen procesadores más lentos y conexiones menos fiables. Estos factores hacen que sea importante revisar el tiempo de carga de las páginas de tu sitio desde una perspectiva móvil en el peor de los casos para entender dónde hay oportunidades reales de mejora.