Aprendizajes para adoptar el atributo de carga estandarizado
Mi objetivo con esta publicación es persuadir a los desarrolladores y colaboradores de la plataforma de CMS (es decir, las personas que desarrollan los núcleos de CMS) de que ahora 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 permitir que otros desarrolladores realicen la personalización mientras implementan la carga diferida. Estos lineamientos provienen de nuestra experiencia en la incorporación de compatibilidad con WordPress, así como en la ayuda a Joomla, Drupal y TYPO3 para implementar la función.
Independientemente de si eres desarrollador de una plataforma de CMS o usuario de un 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 en tu CMS. Consulta la sección Próximos pasos para obtener sugerencias sobre cómo puedes fomentar que tu plataforma de CMS implemente la carga diferida.
Contexto
Durante el último año, la carga diferida de imágenes y marcos de iframes con el atributo loading se convirtió en parte del estándar HTML de WHATWG y se adoptó cada vez más en varios navegadores.
Sin embargo, estos hitos solo sientan las bases para una Web más rápida y que ahorra recursos.
Ahora está en el ecosistema web distribuido para usar el atributo loading.
Los sistemas de administración de contenido potencian alrededor del 60% de los sitios web, por lo que estas plataformas desempeñan un papel fundamental en la adopción de funciones modernas de navegadores en la Web. Algunos CMS de código abierto populares, 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 en otras plataformas de CMS. La carga diferida de contenido multimedia es una función clave de rendimiento web de la que los sitios deberían beneficiarse a gran escala, por lo que se recomienda adoptarla en el nivel principal del CMS.
Razones para implementar la carga diferida ahora
Estandarización
La adopción de funciones de navegador no estandarizadas en los CMS facilita las pruebas generalizadas y puede mostrar posibles áreas de mejora. Sin embargo, el consenso general entre los CMS es que, siempre que una función del navegador no esté estandarizada, se debe implementar preferentemente como una extensión o un complemento para la plataforma respectiva. Solo una vez que se estandariza, se puede considerar una función para su adopción en el núcleo de la plataforma.
Navegadores compatibles
La compatibilidad del navegador con la función es una preocupación similar: la mayoría de los usuarios del CMS deberían poder beneficiarse de la función. Si hay un porcentaje considerable de navegadores en los que la función aún no es compatible, esta debe garantizar que, al menos, no tenga efectos adversos para ellos.
Umbrales de distancia desde el 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 vuelve visible en el viewport del usuario porque el ciclo de carga comienza en una etapa posterior. A diferencia de las soluciones anteriores basadas en JavaScript, los navegadores abordan esto de forma conservadora y, además, pueden ajustar su enfoque en función de los datos de experiencia del usuario en el mundo real, lo que minimiza el impacto, por lo que las plataformas de CMS deberían poder adoptar de forma segura la carga diferida a nivel del navegador.
Recomendaciones de experiencia del usuario
Exige atributos de dimensión en los elementos
Para evitar cambios de diseño, se recomienda desde hace mucho tiempo que el contenido incorporado, como imágenes o iframes, siempre incluya los atributos de dimensión width y height, de modo 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 un 0.1% mayor 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.
Los CMS deben proporcionar atributos de dimensión en todas las imágenes y los iframes. Si esto no es posible para todos los elementos, se recomienda omitir las imágenes de carga diferida que no proporcionan ambos atributos.
Evita la carga diferida de elementos de la mitad superior de la página
Por el momento, se recomienda que los CMS solo agreguen atributos loading="lazy" a las imágenes y los iframes que se encuentran en la mitad inferior de la página para evitar una demora en la métrica Largest Contentful Paint, que en algunos casos puede ser significativa 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 especialmente si el CMS usa un enfoque automatizado para agregar atributos loading, pero incluso en función de la intervención manual, se deben tener en cuenta varios factores, como los diferentes tamaños de viewport y las relaciones de aspecto. Sin embargo, se recomienda omitir las imágenes hero y otras imágenes o iframes que probablemente aparezcan en la mitad superior de la página para que no se carguen de forma diferida.
Evita un resguardo de JavaScript
Si bien JavaScript se puede usar para proporcionar 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 un iframe, lo que causa una demora en los navegadores que sí admiten el atributo. Además, el lanzamiento de una solución basada en JavaScript en los frontends de un CMS a gran escala aumenta la superficie de posibles problemas, lo que es parte de la razón por la 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 los iframes, preferentemente solo para aquellos elementos que incluyen atributos de dimensión.
Si la función está habilitada de forma predeterminada, se ahorrarán más recursos de red que si se tuviera que habilitar de forma manual, por ejemplo, por imagen.
En la medida de lo posible, loading="lazy" solo se debe agregar a los elementos que probablemente aparezcan en la mitad inferior de la página.
Si bien este requisito puede ser complejo de implementar para un CMS debido a la falta de conocimiento del cliente y a los diferentes tamaños de viewport, se recomienda, al menos, usar heurísticas aproximadas para omitir elementos como las imágenes hero que probablemente aparezcan en la mitad superior de la página para que no se carguen de forma diferida.
Permite modificaciones por elemento
Si bien loading="lazy" se debe agregar a las imágenes y los iframes de forma predeterminada, es fundamental permitir omitir el atributo en ciertas imágenes, por ejemplo, para optimizar la LCP. Si el público del CMS se considera, en promedio, más experto en tecnología, este podría ser un control de IU expuesto para cada imagen y iframe que permita inhabilitar la carga diferida para ese elemento.
Como alternativa o además, se podría exponer una API a desarrolladores externos para que puedan realizar cambios similares a través del código.
WordPress, por ejemplo, permite omitir el atributo loading para una etiqueta o un contexto HTML completo o para un elemento HTML específico en el contenido.
Adapta el 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 de la base de datos en el frontend.
Se recomienda que el CMS opte por agregar el atributo sobre la marcha durante la renderización para llevar los beneficios de la carga diferida a cualquier contenido existente. Si el atributo solo se pudiera agregar a través del editor, solo el contenido nuevo o modificado recientemente recibiría los beneficios, lo que reduciría drásticamente el impacto del CMS en el ahorro de recursos de red. Además, agregar el atributo sobre la marcha permitirá realizar modificaciones futuras fácilmente, en caso de que se expandan aún más las capacidades de la carga diferida a nivel del navegador.
Sin embargo, agregar el atributo sobre la marcha debe tener en cuenta un atributo loading potencialmente existente en un elemento y permitir que ese atributo tenga prioridad. De esta manera, el CMS o una extensión para él también podrían implementar el enfoque orientado al editor sin causar un conflicto con los atributos duplicados.
Optimiza el rendimiento del servidor
Cuando se agrega el atributo loading al contenido sobre la marcha con (por ejemplo) un middleware del servidor, la velocidad es una consideración. Según el CMS, el atributo se puede agregar a través del recorrido del DOM o de expresiones regulares, y se recomienda la última opción 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 en el contenido, incluidos sus atributos, y, luego, agregue el atributo loading a cada cadena de etiqueta según corresponda. WordPress, por ejemplo, llega al punto de tener una sola expresión regular general para realizar varias operaciones sobre la marcha en ciertos elementos, de las cuales agregar loading="lazy" es solo una, con una sola expresión regular para facilitar varias funciones. Además, esta forma de optimización es otro motivo por el que se recomienda adoptar la carga diferida en el núcleo de un CMS en lugar de una extensión, ya que permite una mejor optimización del rendimiento del servidor.
Próximos pasos
Consulta si hay un ticket de solicitud de función existente para agregar compatibilidad con la función en tu CMS o abre uno nuevo si aún no hay ninguno. 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 tienes otros desafíos, también me gustaría obtener más información 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 parche o solicitud de extracción.
Foto hero de Colin Watts en Unsplash.