Aprendizajes para adoptar el atributo de carga estandarizado
Mi objetivo con esta publicación es persuadir a los desarrolladores y colaboradores de la plataforma CMS (es decir, las personas que desarrollan núcleos de CMS) de que este es el momento de implementar la compatibilidad con la función de carga diferida de imágenes a nivel del navegador. También compartiré recomendaciones para garantizar experiencias del usuario de alta calidad y habilitar la personalización por parte de otros desarrolladores durante la implementación de la carga diferida. Estos lineamientos se basan en nuestra experiencia de agregar compatibilidad con WordPress y de ayudar a Joomla, Drupal y TYPO3 a implementar la función.
Independientemente de si eres un desarrollador de la plataforma del CMS o un usuario del CMS (es decir, una persona que crea sitios web con un CMS), puedes usar esta publicación para obtener más información sobre los beneficios de la carga diferida a nivel del navegador. Consulta la sección Próximos pasos para obtener sugerencias sobre cómo alentar a tu plataforma del CMS a implementar la carga diferida.
Información general
Durante el año pasado, la carga diferida de imágenes y iframes con el atributo loading se convirtió en parte de la versión estándar de HTML de WhatWG y la adopción de varios navegadores es cada vez mayor.
Sin embargo, estos eventos importantes solo sientan las bases para una Web más rápida y que ahorre más recursos.
Ahora está en el ecosistema web distribuido para usar el atributo loading.
Los sistemas de administración de contenido impulsan a alrededor del 60% de los sitios web, por lo que estas plataformas desempeñan una función vital en la adopción de funciones modernas de los navegadores en la Web. Dado que algunos CMS populares de código abierto, como WordPress, Joomla y TYPO3, ya implementaron la compatibilidad con el atributo loading en las imágenes, veamos sus enfoques y las conclusiones que son relevantes para adoptar la función también en otras plataformas de CMS. Los medios de carga diferida son una función clave de rendimiento web de la que los sitios deberían beneficiarse a gran escala, por lo que se recomienda adoptarlo en el nivel principal del CMS.
El caso para implementar la carga diferida ahora
Estandarización
La adopción de funciones del navegador no estandarizadas en los CMS facilita las pruebas generalizadas y puede detectar posibles áreas de mejora. Sin embargo, el consenso general entre los CMS es que, siempre que la función del navegador no esté estandarizada, es preferible que se implemente como una extensión o un complemento para la plataforma respectiva. Solo una vez estandarizado se puede considerar una función para su adopción en el núcleo de la plataforma.
Navegadores compatibles
La compatibilidad de la función con los navegadores es una preocupación similar: la mayoría de los usuarios del CMS deberían beneficiarse de la función. Si hay un porcentaje considerable de navegadores en los que aún no se admite la función, la función debe garantizar que, al menos, no tenga efectos adversos en ellos.
Umbrales de distancia desde la viewport
Una preocupación común con las implementaciones de carga diferida es que, en principio, aumentan la probabilidad de que una imagen no se cargue una vez que se vuelva visible en el viewport del usuario, ya que el ciclo de carga comienza en una etapa posterior. A diferencia de las soluciones anteriores basadas en JavaScript, los navegadores lo hacen de manera conservadora y, además, pueden ajustar su enfoque en función de datos de experiencia del usuario reales, lo que minimiza el impacto, por lo que la carga diferida a nivel del navegador debería ser segura de adoptar en las plataformas de CMS.
Recomendaciones sobre la experiencia del usuario
Exigir atributos de dimensión en los elementos
Para evitar los cambios de diseño, desde hace mucho tiempo se recomienda que el contenido incorporado, como imágenes o iframes, incluya siempre los atributos de dimensión width y height para que el navegador pueda inferir la relación de aspecto de esos elementos antes de cargarlos. Esta recomendación es relevante independientemente de si un elemento se carga de forma diferida o no. Sin embargo, debido a la probabilidad del 0.1% de que una imagen no se cargue por completo una vez en el viewport, se vuelve un poco más aplicable con la carga diferida.
Preferentemente, los CMS deben proporcionar atributos de dimensión en todas las imágenes y los iframes. Si esto no es posible para todos esos elementos, se recomienda omitir las imágenes de carga diferida que no proporcionan ambos atributos.
Evita la carga diferida de elementos en la mitad superior de la página
Por el momento, se recomienda que los CMS agreguen solo atributos loading="lazy" a las imágenes y los iframes que se colocan en la mitad inferior de la página para evitar una demora en la métrica Mayor procesamiento de imagen con contenido, que en algunos casos puede ser significativo como se descubrió en julio de 2021. Sin embargo, se debe reconocer que es complejo evaluar la posición de un elemento en relación con el viewport antes del proceso de renderización. Esto se aplica en especial si el CMS usa un enfoque automatizado para agregar atributos loading. Sin embargo, incluso según la intervención manual, deben considerarse varios factores, como los diferentes tamaños de viewport y relaciones de aspecto. Aun así, se recomienda encarecidamente omitir las hero images y otras imágenes o iframes que puedan aparecer en la mitad superior de la página para que no se carguen de forma diferida.
Cómo evitar un resguardo de JavaScript
Si bien se puede usar JavaScript para proporcionar una carga diferida a los navegadores que (aún) no admiten el atributo loading, estos mecanismos siempre dependen de quitar inicialmente el atributo src de una imagen o iframe, lo que genera una demora para los navegadores que sí admiten el atributo. Además, el lanzamiento de esta solución basada en JavaScript en los frontends de un CMS a gran escala aumenta el área de superficie para posibles problemas, por lo que ningún CMS importante adoptó la carga diferida en su núcleo antes de la función estandarizada del navegador.
Recomendaciones técnicas
Habilita la carga diferida de forma predeterminada
La recomendación general para los CMS que implementan la carga diferida a nivel del navegador es habilitarla de forma predeterminada, es decir, se debe agregar loading="lazy" a las imágenes y a los iframes, preferentemente solo para los elementos que incluyen atributos de dimensión.
Tener la función habilitada de forma predeterminada generará un ahorro de recursos de red mayor que si se tuviera que habilitar de forma manual, por ejemplo, por imagen.
En la medida de lo posible, loading="lazy" solo debe agregarse a elementos que probablemente aparezcan en la mitad inferior de la página.
Si bien puede ser complejo implementar este requisito en un CMS debido a la falta de conocimiento del cliente y de varios tamaños de viewport, se recomienda al menos usar una heurística aproximada para omitir elementos como hero images que probablemente aparecerán en la mitad superior de la página cuando se carguen de forma diferida.
Permitir modificaciones por elemento
Si bien loading="lazy" se debe agregar a las imágenes y a los iframes de forma predeterminada, es fundamental permitir la omisión del atributo en ciertas imágenes, por ejemplo, para optimizar el LCP. Si el público del CMS se considera, en promedio, más experto en tecnología, este podría ser un control de la IU expuesto para cada imagen e iframe que permita inhabilitar la carga diferida para ese elemento.
De manera alternativa o adicional, una API podría exponerse a desarrolladores externos para que puedan realizar cambios similares a través del código.
Por ejemplo, WordPress permite omitir el atributo loading para una etiqueta HTML completa o un contexto, o para un elemento HTML específico en el contenido.
Retrofit de contenido existente
En términos generales, existen dos enfoques para agregar el atributo loading a los elementos HTML en un CMS:
- Agrega el atributo desde el editor de contenido en el backend y guárdalo de forma persistente en la base de datos.
- Agrega el atributo sobre la marcha cuando renderices contenido desde la base de datos en el frontend.
Se recomienda que el CMS opte por agregar el atributo sobre la marcha durante la renderización, a fin de implementar los beneficios de la carga diferida también en cualquier contenido existente. Si el atributo se pudiera agregar únicamente a través del editor, solo el contenido nuevo o modificado recientemente recibiría los beneficios, lo que reduce drásticamente el impacto del CMS en el ahorro de recursos de red. Además, agregar el atributo sobre la marcha fácilmente permitirá modificaciones futuras con facilidad, en caso de que se amplíen aún más las capacidades de la carga diferida a nivel del navegador.
Sin embargo, agregar el atributo sobre la marcha debería satisfacer un posible atributo loading existente en un elemento y permitir que ese atributo tenga prioridad. De esta manera, el CMS o una extensión también podría implementar el enfoque controlado por el editor sin causar un conflicto con los atributos duplicados.
Cómo optimizar el rendimiento del servidor
Cuando agregas el atributo loading al contenido sobre la marcha usando (por ejemplo) un middleware del servidor, debes tener en cuenta la velocidad. Según el CMS, el atributo podría agregarse a través del recorrido del DOM o mediante expresiones regulares, y esta última se recomienda para mejorar el rendimiento.
El uso de expresiones regulares debe reducirse al mínimo, por ejemplo, una sola regex que recopile todas las etiquetas img y iframe del contenido, incluidos sus atributos y, luego, agregue el atributo loading a cada cadena de etiqueta según corresponda. WordPress, por ejemplo, incluso incluye una sola expresión regular general para realizar varias operaciones sobre la marcha para ciertos elementos, en las que agregar loading="lazy" es solo uno de ellos, con una única expresión regular para facilitar varias funciones. Además, esta forma de optimización es otra razón por la que se recomienda adoptar la carga diferida en el núcleo del CMS en lugar de una extensión, ya que permite una mejor optimización del rendimiento del servidor.
Próximos pasos
Verifica si hay un ticket de solicitud de función para agregar compatibilidad con la función en tu CMS o abre uno nuevo si aún no hay uno. Usa referencias a esta publicación según sea necesario para respaldar tu propuesta.
Envíame un tweet (felixarntz@) si tienes preguntas o comentarios, o para que tu CMS aparezca en esta página si se agregó compatibilidad con la carga diferida a nivel del navegador. Si te encuentras con otros desafíos, también me interesa saber más sobre ellos para encontrar una solución.
Si eres desarrollador de una plataforma de CMS, estudia cómo otros CMS implementaron la carga diferida:
Puedes usar los aprendizajes de tu investigación y las recomendaciones técnicas de esta publicación para comenzar a contribuir con código a tu CMS, por ejemplo, en forma de un parche o una solicitud de extracción.
Foto hero de Colin Watts en Unsplash.