Aprendizajes para adoptar el atributo de carga estandarizado
Mi objetivo con esta publicación es persuadir a los desarrolladores y colaboradores de plataformas 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 la personalización por parte de otros desarrolladores mientras se implementa la carga diferida. Estos lineamientos provienen de nuestra experiencia de agregar compatibilidad con WordPress y ayudar a Joomla, Drupal y TYPO3 a implementar la función.
Independientemente de si eres desarrollador de una plataforma de CMS o 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 puedes alentar a tu plataforma de CMS a implementar la carga diferida.
Fondo
Durante el último año,
la carga diferida de imágenes e iframes con el atributo loading
se
convirtió en parte del estándar HTML de WHATWG
y
ha tenido una adopción creciente por parte de varios navegadores.
Sin embargo, estos hitos solo sientan las bases para una
Web más rápida y que ahorre más recursos.
Ahora, el ecosistema web distribuido debe 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 las funciones de los navegadores modernos
en la Web. Dado que 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
tambié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 a nivel del núcleo del CMS.
Por qué 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 revelar 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 en forma de extensión o complemento para la plataforma correspondiente. Solo una vez que se estandariza, una función se puede considerar para su adopción en el núcleo de la plataforma.
Navegadores compatibles
La compatibilidad de la función con el navegador 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 garantizar que, al menos, no tenga un 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 vuelve 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 abordan esto de forma conservadora y, además, pueden ajustar su enfoque en función de los datos de la experiencia del usuario en el mundo real, lo que minimiza el impacto, por lo que la carga diferida a nivel del navegador debería ser segura para que la adopten las plataformas de CMS.
Recomendaciones para la experiencia del usuario
Exige atributos de dimensión en los elementos
Para evitar los cambios de diseño, se recomienda desde hace mucho tiempo que el contenido incorporado, como las imágenes o los 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 pertinente 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 que esté en el viewport,
se vuelve un poco más aplicable con la carga diferida.
Preferentemente, los CMS deberían proporcionar atributos de dimensión en todas las imágenes y los iframes. Si esto no es posible para cada uno de esos elementos, se recomienda omitir la carga diferida de las imágenes que no proporcionen 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 encuentran en la mitad inferior de la página para evitar un retraso en la métrica Largest Contentful Paint, que, en algunos casos, puede ser significativo, como se descubrió en julio de 2021. Sin embargo, hay que 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 considerar varios factores, como los diferentes tamaños de viewport y las relaciones de aspecto. Aun así, se recomienda omitir la carga diferida de las imágenes hero y otras imágenes o iframes que puedan aparecer en la mitad superior de la página.
Evita un resguardo de JavaScript
Si bien se puede usar JavaScript para
proporcionar carga diferida a los navegadores que (todavía) no admiten el atributo loading,
esos mecanismos siempre se basan en quitar inicialmente el atributo src de una
imagen o un iframe, lo que provoca un retraso para los navegadores que sí admiten el
atributo. Además, implementar una solución basada en JavaScript en los
frontends de un CMS a gran escala aumenta la superficie de posibles problemas,
lo que explica en parte por qué ningún CMS importante había adoptado 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, preferiblemente solo para aquellos elementos que incluyen atributos de dimensión.
Tener la función habilitada de forma predeterminada generará un mayor ahorro de 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 distintos 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 y que 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 el LCP. Si se considera que el público del CMS tiene, en promedio, más conocimientos tecnológicos, podría ser un control de la IU expuesto para cada imagen e 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.
Por ejemplo, WordPress permite omitir el atributo loading para una
etiqueta HTML o un contexto completos
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 que los beneficios de la carga diferida también se apliquen a cualquier contenido existente. Si el atributo solo se pudiera agregar a través del editor, solo las partes de contenido nuevas o modificadas recientemente recibirían 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 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 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 controlado por el editor sin causar un conflicto con atributos duplicados.
Optimiza el rendimiento del servidor
Cuando agregues el atributo loading al contenido sobre la marcha con (por ejemplo) un middleware del servidor, la velocidad es un factor que se debe tener en cuenta. Según el CMS, el atributo se podría agregar a través del recorrido del DOM o de expresiones regulares, y se recomienda esta última opción para mejorar el rendimiento.
El uso de expresiones regulares debe mantenerse 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. Por ejemplo, WordPress llega al punto de
tener una sola expresión regular general para realizar varias operaciones sobre la marcha en ciertos elementos,
de los cuales agregar loading="lazy" es solo uno, usando una sola expresión regular
para facilitar múltiples funciones. Esta forma de optimización es, además, otra razón por la que se recomienda adoptar la carga diferida en el núcleo de un CMS en lugar de una extensión: permite una mejor optimización del rendimiento del servidor.
Próximos pasos
Verifica si existe 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 existe. 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 conocerlos para, con suerte, 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.