Aprendizajes para adoptar el atributo de carga estandarizada
Mi objetivo con esta publicación es persuadir a los desarrolladores y colaboradores de la plataforma de CMS (es decir, las personas que desarrollan 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 habilitar la personalización por parte de otros desarrolladores mientras implementas la carga diferida. Estos lineamientos provienen de nuestra experiencia en la incorporación de compatibilidad con WordPress y en la ayuda para que Joomla, Drupal y TYPO3 implementen la función.
No importa si eres un desarrollador de plataforma de CMS o un usuario de 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 incentivar la implementación de la carga diferida en tu plataforma del CMS.
Información general
Durante el año pasado, la carga diferida de imágenes y iframes con el atributo loading se convirtió en parte del estándar de HTML de WHWG y experimentó una adopción creciente por parte de varios navegadores.
Sin embargo, estos eventos importantes solo sientan las bases para una Web más rápida y que ahorre más recursos.
Ahora se encuentra 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 una función vital para llevar la adopción de funciones modernas de los navegadores a la Web. Con 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 también son relevantes para adoptar la función en otras plataformas de CMS. Los medios de carga diferida son una función clave de rendimiento web que los sitios deberían beneficiar a gran escala, por lo que se recomienda adoptarla a nivel principal de CMS.
El caso para implementar la carga diferida ahora
Estandarización
La adopción de funciones no estandarizadas del navegador 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 una función del navegador no esté estandarizada, es preferible implementarla en forma de una extensión o un complemento para la plataforma respectiva. Solo una vez estandarizada, se puede considerar una función para su adopción en el núcleo de la plataforma.
Navegadores compatibles
La compatibilidad de los navegadores con la función es una preocupación similar: la mayoría de los usuarios de CMS deberían poder beneficiarse de la función. Si hay un porcentaje considerable de navegadores en los que aún no se admite la función, esta debe asegurarse de que, al menos, no tenga ningún efecto adverso 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 haga 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 se enfocan en esto de manera conservadora y, además, pueden ajustar su enfoque en función de los datos de la experiencia del usuario real, lo que minimiza el impacto, de modo que las plataformas de CMS puedan implementar con seguridad la carga diferida en el nivel del navegador.
Recomendaciones de experiencia del usuario
Cómo exigir atributos de dimensión en los elementos
Para evitar los cambios de diseño, hace tiempo que se recomendó 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 sin importar si un elemento se carga de forma diferida o no. Sin embargo, debido a una probabilidad del 0.1% mayor de que una imagen no se cargue por completo una vez en el viewport, se aplica un poco más con la carga diferida en el lugar.
Preferentemente, los CMS deben proporcionar atributos de dimensiones en todos los iframes y las imágenes. 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 los 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 encuentren 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 relativa al viewport antes del proceso de renderización. Esto se aplica especialmente si el CMS usa un enfoque automatizado para agregar atributos loading, pero incluso basado en la intervención manual, se deben considerar varios factores, como los diferentes tamaños de viewport y las relaciones de aspecto. Aun así, se recomienda omitir las imágenes de héroe y otras imágenes o iframes que puedan aparecer en la parte superior de la página para que no se carguen de forma diferida.
Cómo evitar un resguardo de JavaScript
Si bien JavaScript se puede usar para proporcionar una carga diferida a los navegadores que (aún) no admiten el atributo loading, dichos mecanismos siempre dependen de quitar inicialmente el atributo src de una imagen o un iframe, lo que provoca un retraso en los navegadores que sí admiten el atributo. Además, lanzar esta solución basada en JavaScript en los frontends de un CMS a gran escala aumenta el área de superficie para posibles problemas, lo que es uno de los motivos por los que ningún CMS 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 los elementos que incluyan atributos de dimensión.
Tener la función habilitada de forma predeterminada generará un mayor ahorro de recursos de red que si tuviera que habilitarse de forma manual, por ejemplo, para cada imagen.
En la medida de lo posible, loading="lazy" solo debe agregarse a los elementos que probablemente aparezcan en la mitad inferior de la página.
Si bien la implementación de este requisito en un CMS puede ser compleja debido a la falta de conocimiento del cliente y los diversos tamaños de viewport, se recomienda, al menos, usar una heurística aproximada para omitir elementos como las hero images que puedan aparecer en la mitad superior de la página para que no se carguen de forma diferida.
Permitir modificaciones por elemento
Si bien loading="lazy" debe agregarse a las imágenes y los iframes de forma predeterminada, es fundamental permitir que se omita el atributo en ciertas imágenes; por ejemplo, con el objetivo de optimizar para LCP. Si el público del CMS se considera, en promedio, experto en tecnología, esto podría ser un control de IU expuesto para cada iframe y imagen que permita inhabilitar la carga diferida de 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 un contexto o etiqueta HTML completo, o bien un elemento HTML específico del contenido.
Contenido existente de Retrofit
En términos generales, existen dos enfoques para agregar el atributo loading a los elementos HTML en un CMS:
- Puedes agregar el atributo desde el editor de contenido del backend y guardarlo en la base de datos de forma persistente.
- Agrega el atributo sobre la marcha cuando renderices contenido de la base de datos en el frontend.
Se recomienda que el CMS agregue el atributo en el momento durante el procesamiento para ofrecer también los beneficios de la carga diferida en cualquier contenido existente. Si el atributo solo se pudiera agregar a través del editor, solo los fragmentos de contenido nuevos o modificados recientemente recibirían los beneficios, lo que reduciría de forma drástica el impacto del CMS en el ahorro de recursos de red. Además, agregar el atributo sobre la marcha permitirá fácilmente modificaciones futuras si las capacidades de carga diferida a nivel del navegador se expanden aún más.
Sin embargo, si agregas el atributo sobre la marcha, se debería considerar un atributo loading que posiblemente ya existe en un elemento y debes 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.
Optimiza el rendimiento del servidor
Cuando se agrega el atributo loading al contenido sobre la marcha mediante (por ejemplo) un middleware del servidor, la velocidad es una consideración. Según el CMS, se puede agregar el atributo mediante expresiones regulares o el recorrido del DOM, 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 recopila todas las etiquetas img y iframe en el contenido, incluidos sus atributos, y, luego, agrega el atributo loading a cada cadena de etiqueta según corresponda. WordPress, por ejemplo, llega a tener una sola expresión regular general para realizar varias operaciones sobre la marcha a ciertos elementos. Para ello, agregar loading="lazy" es solo uno y usar una única expresión regular a fin de 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
Verifica 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 las 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 en el nivel del navegador. Si te encuentras con otros desafíos, también me interesa aprender más sobre ellos para encontrar una solución.
Si eres un desarrollador de la plataforma de CMS, analiza cómo otros CMS implementaron la carga diferida:
Puedes usar los hallazgos 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.