Una recopilación de las prácticas recomendadas que el equipo de Chrome DevRel considera que son las formas más eficaces de mejorar el rendimiento de las Métricas web esenciales en 2023.
A lo largo de los años, en Google hemos hecho muchas recomendaciones a los desarrolladores web sobre cómo mejorar el rendimiento.
Si bien cada una de estas recomendaciones, individualmente, puede mejorar el rendimiento de muchos sitios, el conjunto completo de recomendaciones es abrumador y, en realidad, no hay forma de que una persona o un sitio pueda seguirlos a todos.
A menos que el rendimiento web sea tu día a día, es probable que no sea evidente qué recomendaciones tendrán el mayor impacto positivo en tu sitio. Por ejemplo, quizás hayas leído que implementar CSS críticos puede mejorar el rendimiento de carga y quizás hayas escuchado que es importante optimizar tus imágenes. Pero, si no tienes tiempo para trabajar en ambas cosas, ¿cómo decidirías cuál elegir?
En el equipo de Chrome, dedicamos el último año a intentar responder esta pregunta: ¿cuáles son las recomendaciones más importantes que podemos dar a los desarrolladores para ayudarlos a mejorar el rendimiento de sus usuarios?
Para responder correctamente esta pregunta, debemos considerar no solo los méritos técnicos de una recomendación determinada, sino también los factores humanos y organizacionales que influyen en la probabilidad de que los desarrolladores realmente puedan adoptar estas recomendaciones. En otras palabras, algunas recomendaciones pueden tener un gran impacto en teoría, pero, en realidad, muy pocos sitios tendrán el tiempo o los recursos para implementarlas. Del mismo modo, algunas recomendaciones son fundamentales, pero la mayoría de los sitios web ya siguen estas prácticas.
En resumen, queremos que nuestra lista de recomendaciones principales sobre el rendimiento de la Web se centre en lo siguiente:
- Las recomendaciones que consideramos que tendrán el mayor impacto en el mundo real
- Recomendaciones que son relevantes y aplicables a la mayoría de los sitios
- Las recomendaciones que son realistas para la mayoría de los desarrolladores implementar
Durante el último año, dedicamos mucho tiempo a auditar el conjunto completo de recomendaciones de rendimiento que hacemos y a evaluar cada una de ellas (de forma cualitativa y cuantitativa) en función de los tres criterios mencionados anteriormente.
En esta publicación, se describen las recomendaciones principales para mejorar el rendimiento de cada una de las métricas de las Métricas web esenciales. Si es la primera vez que utilizas el rendimiento web, o si estás tratando de decidir qué te dará el máximo provecho de tu dinero, creemos que estas recomendaciones son el mejor punto de partida.
Procesamiento de imagen con contenido más grande (LCP)
Nuestro primer conjunto de recomendaciones es el de Largest Contentful Paint (LCP), que mide el rendimiento de carga. De las tres Métricas web esenciales, el LCP es la que tiene dificultades para la mayor cantidad de sitios (actualmente, solo alrededor de la mitad de los sitios de la Web alcanza el umbral recomendado), así que comencemos por ahí.
Asegúrate de que el recurso LCP sea detectable desde la fuente HTML
Según el informe web de 2022 de HTTP Archive, el 72% de las páginas para dispositivos móviles tienen una imagen como elemento LCP, lo que significa que, para que la mayoría de los sitios optimicen su LCP, deberán asegurarse de que esas imágenes se puedan cargar rápidamente.
Lo que no es evidente para muchos desarrolladores es que el tiempo que tarda en cargar una imagen es solo una parte del desafío. Otro aspecto fundamental es el tiempo antes de que comience a cargarse una imagen, y los datos de archivos HTTP sugieren que, en realidad, muchos sitios se equivocan.
De hecho, de las páginas en las que el elemento LCP era una imagen, el 39% de esas imágenes tenían URL de origen que no eran detectables en la fuente del documento HTML. En otras palabras, esas URLs no se encontraron en atributos HTML estándares (como <img src="..."> o <link rel="preload" href="...">), lo que permitiría al navegador descubrirlas rápidamente y comenzar a cargarlas al instante.
Si una página necesita esperar a que los archivos CSS o JavaScript se descarguen, analicen y procesen por completo antes de que la imagen comience a cargarse, es posible que ya sea demasiado tarde.
Como regla general, si tu elemento LCP es una imagen, la URL de esta siempre debe ser detectable desde la fuente HTML. Estas son algunas sugerencias para hacerlo posible:
Carga la imagen usando un elemento
<img>con el atributosrcosrcset. No uses atributos no estándar, comodata-src, que requieran JavaScript para renderizarse, ya que siempre serán más lentos. El 9% de las páginas ocultan su imagen LCP detrás dedata-src.Prefiere la renderización del servidor (SSR) en lugar de la del cliente (CSR), ya que el SSR implica que el lenguaje de marcado de la página completa (incluida la imagen) está presente en la fuente HTML. Las soluciones de CSR requieren que JavaScript se ejecute antes de que se pueda descubrir la imagen.
Si es necesario hacer referencia a tu imagen desde un archivo CSS o JS externo, puedes incluirla en la fuente HTML a través de una etiqueta
<link rel="preload">. Ten en cuenta que el escáner de precarga del navegador no puede detectar las imágenes a las que se hace referencia mediante los estilos intercalados. Por lo tanto, aunque se encuentren en la fuente HTML, su descubrimiento podría seguir bloqueado en la carga de otros recursos, por lo que la precarga puede ayudar en estos casos.
Para ayudarte a comprender si tu imagen LCP tiene problemas de visibilidad, Lighthouse lanzará una nueva auditoría en la versión 10.0 (prevista para enero de 2023).
Garantizar que el recurso LCP sea detectable desde la fuente HTML puede llevar a mejoras medibles y, además, desbloquea oportunidades adicionales para priorizar el recurso, que es nuestra próxima recomendación.
Asegúrate de que el recurso LCP esté priorizado
Asegurarse de que el recurso LCP se pueda descubrir desde la fuente HTML es un primer paso fundamental para garantizar que el recurso LCP pueda comenzar a cargarse antes, pero otro paso importante es garantizar que la carga de ese recurso esté priorizada y no se ponga en cola detrás de un montón de otros recursos menos importantes.
Por ejemplo, aunque tu imagen LCP esté presente en la fuente HTML con una etiqueta <img> estándar, si tu página incluye una docena de etiquetas <script> en la <head> del documento antes de la etiqueta <img>, es posible que pase un tiempo antes de que tu recurso de imagen comience a cargarse.
La manera más fácil de resolver este problema es brindarle al navegador una sugerencia sobre los recursos que tienen la prioridad más alta configurando el nuevo atributo fetchpriority="high" en la etiqueta <img> o <link> que carga tu imagen LCP. Esto le indica al navegador que lo cargue antes en lugar de esperar a que se completen esas secuencias de comandos.
Según el Web Almanac, solo el 0.03% de las páginas aptas aprovechan esta nueva API, lo que significa que hay muchas oportunidades para que la mayoría de los sitios de la Web mejoren el LCP con muy poco trabajo. Si bien por el momento el atributo fetchpriority solo es compatible con los navegadores basados en Chromium, esta API es una mejora progresiva que otros navegadores simplemente ignoran, por lo que recomendamos que los desarrolladores la usen ahora.
En el caso de los navegadores que no son de Chromium, la única manera de garantizar que el recurso LCP tenga prioridad sobre otros recursos es consultarlo antes en el documento. Con el ejemplo de un sitio con muchas etiquetas <script> en el <head> del documento, si quieres asegurarte de que tu recurso LCP tenga prioridad por sobre esos recursos de secuencias de comandos, puedes agregar una etiqueta <link rel="preload"> antes de cualquiera de esas secuencias o moverlas a debajo del <img> más adelante en el <body>. Si bien funciona, es menos ergonómico que el uso de fetchpriority, por lo que esperamos que otros navegadores agreguen compatibilidad pronto.
Otro aspecto crítico de priorizar el recurso LCP es asegurarte de no hacer nada que le impida anular su prioridad, como agregar el atributo loading="lazy". Actualmente, el 10% de las páginas configura loading="lazy" en su imagen LCP. Ten cuidado con las soluciones de optimización de imágenes que aplican de manera indiscriminada el comportamiento de carga diferida a todas las imágenes. Si proporcionan una forma de anular ese comportamiento, asegúrate de usarlo para la imagen LCP. Si no estás seguro de cuál imagen será el LCP, intenta usar heurísticas para elegir una opción razonable.
Aplazar los recursos no críticos es otra forma de aumentar de manera efectiva la prioridad relativa del recurso LCP. Por ejemplo, las secuencias de comandos que no activan la interfaz de usuario (como las de estadísticas o los widgets sociales) se pueden posponer de forma segura hasta después de que se active el evento load, lo que garantiza que no competirán con otros recursos críticos (como el recurso LCP) por el ancho de banda de la red.
En resumen, debes seguir estas prácticas recomendadas para asegurarte de que el recurso LCP se cargue con anticipación y con prioridad alta:
- Agrega
fetchpriority="high"a la etiqueta<img>de tu imagen de LCP. Si el recurso LCP se carga con una etiqueta<link rel="preload">, no temas, ya que también puedes establecerfetchpriority="high"en eso. - Nunca configures
loading="lazy"en la etiqueta<img>de la imagen de LCP. De esta manera, se reducirá la prioridad de la imagen y se retrasará su inicio. - Aplaza los recursos que no sean críticos cuando sea posible. Puedes moverlos al final de tu documento, usar la carga diferida nativa para imágenes o iframes, o cargarlos de forma asíncrona a través de JavaScript.
Utiliza una CDN para optimizar el TTFB de documentos y recursos
Las dos recomendaciones anteriores se centraron en garantizar que tu recurso LCP se descubra con anticipación y se priorice para que pueda comenzar a cargarse de inmediato. La pieza final de este rompecabezas es asegurarse de que la respuesta inicial del documento también llegue lo más rápido posible.
El navegador no puede comenzar a cargar ningún subrecurso hasta que reciba el primer byte de la respuesta inicial del documento HTML, y cuanto antes sea eso, antes todo lo demás también puede empezar a suceder.
Este tiempo se conoce como tiempo hasta el primer byte (TTFB) y la mejor manera de reducir el TTFB es la siguiente:
- Ofrece tu contenido lo más cerca posible de tus usuarios geográficamente
- Almacena en caché ese contenido para que el contenido solicitado recientemente se pueda volver a publicar rápidamente.
La mejor manera de realizar estas dos tareas es usar una CDN. Las CDN distribuyen tus recursos a servidores perimetrales, que están distribuidos en todo el mundo, lo que limita la distancia que esos recursos tienen que recorrer por cable para tus usuarios. Por lo general, las CDN también tienen controles detallados de almacenamiento en caché que se pueden personalizar y optimizar para las necesidades del sitio.
Muchos desarrolladores están familiarizados con el uso de una CDN para alojar elementos estáticos, pero las CDN pueden entregar y almacenar documentos HTML en caché, incluso aquellos que se generan de forma dinámica.
Según el Formulario web, solo el 29% de las solicitudes de documentos HTML se enviaron desde una CDN, lo que significa que existe una gran oportunidad para que los sitios reclamen ahorros adicionales.
Estas son algunas sugerencias para configurar las CDN:
- Considera aumentar el tiempo durante el cual se almacena en caché el contenido (por ejemplo, ¿es fundamental que el contenido siempre esté actualizado? ¿O puede estar inactivo unos minutos?).
- Tal vez, incluso, considere almacenar el contenido en caché de manera indefinida y, luego, borrar definitivamente la caché cuando realice una actualización.
- Explora si puedes trasladar la lógica dinámica que se ejecuta actualmente en el servidor de origen al perímetro (una función de la mayoría de las CDN modernas).
En general, cada vez que puedes entregar contenido directamente desde el perímetro (y evitando un viaje al servidor de origen), supone una mejora en el rendimiento. Incluso en los casos en los que tienes que realizar el recorrido hasta el servidor de origen, las CDN suelen estar optimizadas para hacerlo mucho más rápido, por lo que es una victoria en cualquiera de los dos casos.
Cambio de diseño acumulado (CLS)
El siguiente conjunto de recomendaciones es para el Cambio de diseño acumulado (CLS), que mide la estabilidad visual en páginas web. Si bien CLS mejoró mucho en la Web desde 2020, cerca de un cuarto de los sitios web aún no cumplen con el umbral recomendado, por lo que sigue existiendo una gran oportunidad para que muchos sitios mejoren la experiencia del usuario.
Establece tamaños explícitos en cualquier contenido que se cargue desde la página
Los cambios de diseño suelen ocurrir cuando se mueve el contenido existente después de que termina de cargarse otro contenido. Por lo tanto, la forma principal de mitigar esto es reservar el espacio requerido con anticipación tanto como sea posible.
La manera más directa de corregir los cambios de diseño causados por imágenes sin tamaño es establecer explícitamente los atributos width y height (o propiedades de CSS equivalentes). Sin embargo, según el archivo HTTP, el 72% de las páginas tienen al menos una imagen sin tamaño. Sin un tamaño explícito, los navegadores establecerán inicialmente una altura predeterminada de 0px y podrían provocar un cambio de diseño notable cuando se cargue la imagen y se descubran las dimensiones. Esto representa una gran oportunidad para la Web colectiva, que requiere mucho menos esfuerzo que algunas de las otras recomendaciones sugeridas en este artículo.
También es importante tener en cuenta que las imágenes no son los únicos colaboradores de CLS. Los cambios de diseño pueden deberse a otros contenidos que suelen cargarse después de que se renderiza la página inicialmente, como los anuncios de terceros o los videos incorporados. La propiedad aspect-ratio puede ayudar a combatir esto. Es una función de CSS relativamente nueva que permite a los desarrolladores proporcionar de manera explícita una relación de aspecto a las imágenes y a los elementos que no son de imágenes. De esta manera, podrás establecer un elemento width dinámico (por ejemplo, según el tamaño de la pantalla) y hacer que el navegador calcule automáticamente la altura adecuada, tal como lo hace para las imágenes con dimensiones.
A veces, no es posible conocer el tamaño exacto del contenido dinámico, ya que es, por naturaleza, dinámico. Sin embargo, aunque no conozcas el tamaño exacto, puedes tomar medidas para reducir la gravedad de los cambios de diseño. Configurar un elemento min-height razonable casi siempre es mejor que permitir que el navegador use la altura predeterminada de 0px para un elemento vacío. El uso de un min-height también suele ser una solución fácil, ya que permite que el contenedor alcance la altura final del contenido si es necesario. Solo se redujo la cantidad de crecimiento del importe total a un nivel con suerte más tolerable.
Asegúrate de que las páginas sean aptas para la bfcache
Los navegadores utilizan un mecanismo de navegación llamado memoria caché atrás/adelante (o bfcache para abreviar) a fin de cargar al instante una página anterior o posterior en el historial del navegador directamente desde una instantánea de la memoria.
La bfcache es una optimización importante del rendimiento a nivel del navegador y elimina por completo los cambios de diseño durante la carga de la página, que para muchos sitios es donde se produce la mayor parte de su CLS. La introducción de la bfcache causó la mejora más importante en el CLS que vimos en 2022.
A pesar de esto, una cantidad significativa de sitios web no son aptos para la bfcache y, por lo tanto, se están perdiendo esta mejora de rendimiento web gratuito durante una cantidad significativa de navegaciones. A menos que tu página esté cargando información sensible que no quieres que se restablezca de la memoria, asegúrate de que tus páginas sean aptas.
Los propietarios de los sitios deben verificar que sus páginas sean aptas para la bfcache y resolver los motivos por los que no lo son. Chrome ya tiene un verificador de bfcache en Herramientas para desarrolladores y, este año, planeamos mejorar las herramientas con una nueva auditoría de Lighthouse que realiza una prueba similar y una API para medir esto en el campo.
Si bien incluimos la bfcache en la sección de CLS, dado que vimos los mayores beneficios hasta ahora, la bfcache también mejorará otras Métricas web esenciales. Es una de las diversas navegaciones instantáneas disponibles para mejorar significativamente la navegación de las páginas.
Evita las animaciones o transiciones que usen propiedades de CSS que inducen el diseño
Otra fuente común de cambios de diseño es cuando los elementos se animan. Por ejemplo, los banners de cookies o de otros banners de notificaciones que se deslizan desde la parte superior o inferior suelen contribuir al CLS. Esto es particularmente problemático cuando estos banners quitan otro contenido del camino, pero incluso cuando no lo hacen, animarlos aún puede afectar el CLS.
Si bien los datos de HTTP Archive no pueden conectar de manera concluyente las animaciones con los cambios de diseño, los datos muestran que las páginas que animan cualquier propiedad de CSS que podría afectar el diseño tienen un 15% menos de probabilidades de tener un CLS "bueno" que las páginas en general. Algunas propiedades están asociadas con un CLS peor que otras. Por ejemplo, las páginas con anchos margin o border animados tienen un CLS "deficiente" que es casi el doble de la tasa que las páginas en general se evalúan como deficientes.
Quizás no te sorprenda, ya que cada vez que realizas una transición o animas cualquier propiedad de CSS que induce diseño, generará cambios de diseño, y, si esos cambios no ocurren dentro de los 500 milisegundos de una interacción del usuario, afectarán a CLS.
Lo que podría sorprender a algunos desarrolladores es que esto ocurre incluso en casos en los que el elemento se toma fuera del flujo de documentos normal. Por ejemplo, los elementos de posición absoluta que animan top o left provocarán cambios de diseño, incluso si no desplazan otro contenido. Sin embargo, si, en lugar de animar top o left, animarás transform:translateX() o transform:translateY(), no hará que el navegador actualice el diseño de la página ni producirá cambios en el diseño.
Por mucho tiempo, se prefiere la animación de las propiedades de CSS que se pueden actualizar en el subproceso del compositor del navegador, una práctica recomendada de rendimiento porque traslada ese trabajo a la GPU y fuera del subproceso principal. Además de ser una práctica recomendada de rendimiento general, también puede ayudar a mejorar CLS.
Como regla general, nunca animes ni realices la transición de una propiedad de CSS que requiera que el navegador actualice el diseño de la página, a menos que lo hagas cuando el usuario presione o presione una tecla (aunque no hover). Además, siempre que sea posible, prioriza las transiciones y animaciones que usen la propiedad transform de CSS.
La auditoría de Lighthouse Evitar animaciones no compuestas advertirá cuando una página anime propiedades de CSS potencialmente lentas.
Retraso de primera entrada (FID)
El último conjunto de recomendaciones es el Retraso de primera entrada (FID), que mide la capacidad de respuesta de una página a las interacciones del usuario. Si bien la mayoría de los sitios de la Web actualmente tienen una puntuación muy buena en cuanto a los FID, documentamos las deficiencias de la métrica FID en el pasado y creemos que todavía existen muchas oportunidades para que los sitios mejoren su capacidad de respuesta general a las interacciones de los usuarios.
Nuestra nueva métrica Interaction to Next Paint (INP) es un posible sucesor de FID, y todas las recomendaciones que aparecen a continuación se aplican de la misma manera tanto para FID como para INP. Dado que los sitios tienen un rendimiento inferior en el INP que en el FID, especialmente en los dispositivos móviles, recomendamos a los desarrolladores que consideren seriamente estas recomendaciones de capacidad de respuesta, a pesar de tener un FID "bueno".
evitar o dividir tareas largas
Las tareas son cualquier trabajo discreto que realiza el navegador. Las tareas incluyen la renderización, el diseño, el análisis, la compilación y la ejecución de secuencias de comandos. Cuando las tareas se convierten en tareas largas, es decir, de 50 milisegundos o más, bloquean el subproceso principal para que no pueda responder rápidamente a las entradas del usuario.
Según el documento web, existe mucha evidencia que sugiere que los desarrolladores podrían hacer más para evitar o dividir tareas largas. Si bien dividir las tareas largas puede no ser tan difícil como otras recomendaciones de este artículo, es menos difícil que otras técnicas que no se ofrecen en este artículo.
Si bien siempre debes esforzarte por hacer el menor trabajo posible en JavaScript, puedes ayudar al subproceso principal a dividir las tareas largas en tareas más pequeñas. Puedes lograr esto si rinde al subproceso principal con frecuencia para que las actualizaciones de renderización y otras interacciones del usuario ocurran con mayor rapidez.
Otra opción es considerar el uso de APIs como isInputPending y la API de Scheduler. isInputPending es una función que muestra un valor booleano que indica si una entrada del usuario está pendiente. Si muestra true, puedes ceder el paso al subproceso principal para que pueda controlar la entrada pendiente del usuario.
La API de Scheduler es un enfoque más avanzado que te permite programar trabajos según un sistema de prioridades que tienen en cuenta si el trabajo que se realiza es visible para el usuario o está en segundo plano.
Al dividir las tareas largas, le das al navegador más oportunidades de adaptarse a trabajos críticos visibles para el usuario, como tratar con interacciones y cualquier actualización de representación resultante.
Cómo evitar JavaScript innecesario
No hay duda de ello: los sitios web están enviando más código JavaScript que nunca, y parece que la tendencia no va a cambiar en ningún momento. Si envías demasiado JavaScript, creas un entorno en el que las tareas compiten por la atención del subproceso principal. Sin duda, esto puede afectar la capacidad de respuesta de tu sitio web, especialmente durante ese período crucial de inicio.
Sin embargo, este no es un problema sin resolver. Tiene algunas opciones:
- Utilice la herramienta de cobertura en las Herramientas para desarrolladores de Chrome para encontrar el código sin usar en los recursos de su sitio web. Si reduces el tamaño de los recursos que necesitas durante el inicio, puedes asegurarte de que tu sitio web tarde menos tiempo en analizar y compilar código, lo que genera una experiencia inicial del usuario más fluida.
- A veces, el código sin usar que encuentras con la herramienta de cobertura se marca como "no usado" porque no se ejecutó durante el inicio, pero es necesario para algunas funcionalidades en el futuro. Este es un código que puedes mover a un paquete separado mediante la división de código.
- Si utiliza un administrador de etiquetas, asegúrese de revisar sus etiquetas de forma periódica para asegurarse de que estén optimizadas o, incluso, si se siguen utilizando. Las etiquetas anteriores sin código sin utilizar se pueden borrar para reducir el tamaño del JavaScript de tu administrador de etiquetas y aumentar su eficiencia.
Cómo evitar actualizaciones de renderización grandes
JavaScript no es lo único que puede afectar la capacidad de respuesta de tu sitio web. La renderización puede ser un tipo de trabajo costoso en sí mismo. Además, cuando se producen grandes actualizaciones de renderización, estas pueden interferir en la capacidad de tu sitio web para responder a las entradas de los usuarios.
Optimizar el trabajo de renderización no es un proceso sencillo y, a menudo, depende de lo que se quiera lograr. Aun así, existen algunas medidas que puedes tomar para asegurarte de que las actualizaciones de renderización sean razonables y no se extiendan en tareas largas:
- Evita usar
requestAnimationFrame()para realizar trabajos no visuales. Las llamadas derequestAnimationFrame()se controlan durante la fase de renderización del bucle de eventos y, cuando hay demasiado trabajo durante este paso, las actualizaciones de renderización pueden retrasarse. Es esencial que cualquier trabajo que hagas conrequestAnimationFrame()se reserve estrictamente para tareas que involucran actualizaciones de renderización. - Mantén un tamaño pequeño del DOM. El tamaño del DOM y la intensidad del trabajo de diseño están correlacionados. Cuando el procesador debe actualizar el diseño para un DOM muy grande, el trabajo requerido para volver a calcular su diseño puede aumentar significativamente.
- Usa la contención de CSS. La contención de CSS se basa en la propiedad
containde CSS, que da instrucciones al navegador sobre cómo realizar el trabajo de diseño para el contenedor en el que está configurada la propiedadcontain, incluido el aislamiento del alcance del diseño y la renderización a una raíz específica en el DOM. No siempre es un proceso sencillo, pero si aíslas áreas que contienen diseños complejos, puedes evitar realizar trabajos de diseño y renderización para ellos que no sean necesarios.
Conclusión
Mejorar el rendimiento de las páginas puede parecer una tarea abrumadora, especialmente si hay una gran cantidad de orientación en la Web para tener en cuenta. Sin embargo, si te enfocas en estas recomendaciones, puedes abordar el problema con enfoque y propósito y, con suerte, cambiar las Métricas web esenciales de tu sitio web.
Si bien las recomendaciones que se mencionan aquí no son exhaustivas, creemos que, según un análisis cuidadoso del estado de la Web, son las formas más eficaces en que los sitios pueden mejorar el rendimiento de las Métricas web esenciales en 2023.
Si quieres ir más allá de las recomendaciones que se mencionan aquí, consulta estas guías de optimización para obtener más información:
Celebremos un nuevo año y una Web más rápida para todos. Logra que tus sitios sean rápidos para los usuarios en todas las formas que más importan.
Foto de Devin Avery