Web más rápido, fácil y rápidamente: Nuevas tecnologías y herramientas para desarrolladores

Recientemente di una charla en el meetup de nuestra comunidad Frontendisti.cz en Pilsen con diez consejos sobre novedades en la velocidad web, diseñada específicamente para desarrolladores.

Vamos a repasar estas tecnologías y herramientas frescas, recién salidas del horno, también en forma escrita. Los desarrolladores pueden usar el siguiente texto como una guía de lo que pueden aprender durante las vacaciones para comenzar a crear sitios web más rápidos a partir de septiembre.

No voy a dar muchas vueltas, así que vamos directamente a los consejos.

1) WebP y AVIF, todavía poco utilizados pero ahorradores de imágenes#

Simplificando un poco, los formatos de imagen tradicionales tienen sus usos principales:

• Gif se usa para animaciones
• JPEG maneja compresión con pérdida
• PNG soporta transparencia parcial
• SVG es el único formato que maneja vectores

Los nuevos formatos de imagen WebP y AVIF soportan compresión con y sin pérdida, animaciones y transparencia parcial. Todo esto con un tamaño de archivo significativamente menor.

Todavía necesitarás SVG para vectores, pero todos los demás formatos antiguos quedan relegados por los nuevos.

¿No estás usando aún WebP ni AVIF? Deberías considerar hacerlo:

• WebP tiene prácticamente soporte total en todos los navegadores modernos.
• Para el formato Avif estamos esperando a Microsoft y su navegador Edge. Pero gracias a la etiqueta picture no tenemos que esperar tanto.

Sirve siempre imágenes en WebP y, si puedes, considera también Avif.

2) Priority Hints, acelera LCP en un abrir y cerrar de ojos#

Priority Hints es el condimento del optimizador de la métrica LCP (Largest Contentful Paint).

Preload es útil ocasionalmente para aumentar la prioridad de carga de un elemento específico, como fuentes:

<link rel="preload" href="font-1.woff2" as="font" type="font/woff2" crossorigin />

El nuevo atributo fetchpriority permite definir una prioridad más alta de carga en un elemento HTML. También permite reducir la prioridad.

Tomemos por ejemplo dos imágenes en un carrusel. Aumentaré la prioridad de la primera y reduciré la de la segunda. Esto hará que la primera se cargue y se muestre mucho más rápido, mejorando mi métrica LCP:

<img fetchpriority="high" href="image-1.webp" /> <img fetchpriority="low" href="image-2.webp" />

Es muy interesante la posibilidad de reducir la prioridad de descarga de un archivo usando fetch en JS:

<script>
  fetch('https://example.com/', { priority: 'low' }).then((data) => {
    // Ejecutamos fetch con mayor prioridad
  });
</script>

En la grabación de la charla (ver arriba) mencioné la posibilidad de aumentar la prioridad de fetch, pero eso es un error. Al añadir prioridad a fetch, solo se puede reducir. La prioridad más alta es su estado por defecto.

Preload es compatible con todos los navegadores. Fetchpriority solo está disponible en aquellos con motor Chromium, pero Safari también está en camino.

La falta de soporte en Firefox (y por ahora también en Safari) no debería ser un gran problema. Veámoslo desde la perspectiva de la mejora progresiva: algunos usuarios obtendrán la ventaja de una carga más rápida, pero la falta de soporte en otros no rompe nada.

Solo ten cuidado, con el condimento hay que ser moderado. Usa el cambio de prioridades solo cuando realmente sepas lo que estás haciendo y puedas medir los impactos directamente en el navegador.

3) aspect-ratio, todo lo asíncrono debe tener proporciones#

Esta imagen es bonita, pero triste:

<img src="image.webp" alt="Image" />

¿Sabes por qué? El navegador probablemente tendrá que volver a dibujar el contenido debajo de él después de renderizarlo. Así es mejor:

<img src="image.webp" width="500" height="500" alt="Image" />

Siempre define los atributos width y height para las imágenes. Esto sirve para reservar espacio. Así se evita el cambio de diseño y no empeora la métrica CLS (Cumulative Layout Shift).

¿No tienes una imagen, sino quizás un componente de JavaScript? Usa aspect-ratio:

<p style="aspect-ratio: 4/3"></p>

La propiedad CSS aspect-ratio establece la proporción de aspecto para elementos que no son imágenes. Elimina la necesidad de usar el "truco del padding".

El soporte es completo en todos los navegadores modernos, ver width/height y aspect-ratio. Usa esto para todos los elementos asíncronos, incluyendo anuncios.

4) size-adjust, evita el salto de diseño causado por las fuentes#

Puedes ver el problema en la siguiente imagen de optimización para nuestro cliente, Sazka.cz:

Un problema común en el área del cambio de diseño, medido por la métrica CLS, es el diferente tamaño de las fuentes del sistema y las propias.

El descriptor size-adjust aborda esto:

@font-face {
  font-family: 'Montserrat-fallback';
  size-adjust: 113.56999999999995%;
  src: local('Arial Bold'), local('Arial');
}

Este ajuste adapta el tamaño de las fuentes del sistema a las propias y minimiza los cambios de diseño, y por lo tanto el empeoramiento de CLS debido a las fuentes propias.

Lo soportan todos los navegadores excepto Safari. Pero nuevamente, no importa.

5) BFcache, o cómo Chrome finalmente se despertó#

BFcache es la abreviatura de "back & forward cache". Es una caché en el navegador que almacena las páginas navegadas en el historial del navegador. No es nada nuevo, pero puede que te sorprenda saber que Chrome aprendió esta característica correctamente hasta ahora.

La aceleración del sitio web con back/forward cache es visible a simple vista:

Implementar correctamente BFcache (y no romper, por ejemplo, la medición u otras cosas) es bastante complicado. Es mejor leer más sobre ello, por ejemplo, en el enlace anterior.

Lo importante es que, como desarrolladores, no deberías usar, entre otras cosas, las siguientes características:

• Eventos unload, beforeunload.
• Cabeceras Cache-Control: no-store.
• Referencias a window.opener.

Puedes probar el soporte de BFcache en tus sitios en DevTools de Chrome. Ya sea en la pestaña Application o a través de Lighthouse.

El soporte de BFcache es completo ahora que Chrome se ha puesto en marcha. Hay estudios de caso que dicen que puede ayudar realmente mucho. Todavía no hemos notado una mejora drástica en la velocidad de nuestros clientes, más bien vemos BFcache solo como uno de los pasos potencialmente fáciles para un leve avance hacia una mejor velocidad. Es similar a la implementación de la compresión Brotli.

6) Prerender, una nueva versión de pre-renderizado de páginas#

Con instrucciones de "prerender" se puede, durante la estancia del usuario en una página, indicar que deseas descargar y preparar para renderizar otra página.

Es especialmente útil en navegaciones directas como el proceso de compra.

El prerenderizado también puede tener un gran impacto en la experiencia del usuario. Hubo un tiempo en que el prerenderizado de páginas estaba bastante "de moda" en la comunidad de desarrolladores:

<link rel="prerender" href="/next-page/" />

Este método antiguo de prerenderizado será eliminado de Chrome. No es adecuado principalmente debido a su excesiva simplicidad.

La nueva instrucción para prerendering, a partir de Chrome 108, se define así:

<script type="speculationrules">
  {
    "prerender": [
      {
        "source": "list",
        "urls": ["next.html", "next2.html"]
      }
    ]
  }
</script>

Observa el término speculationrules. Sí, realmente se trata de "reglas especulativas". Expresamos con ellas la probabilidad de que el usuario pueda continuar a ciertas páginas específicas. En la próxima versión de la implementación en Chrome no debería faltar también la expresión numérica de esta probabilidad.

Con soporte puedes contar, nuevamente, solo en navegadores basados en Chromium. ¿Y nosotros? Con los clientes, estamos esperando cómo se desarrolla.

7) INP, una métrica completamente nueva de interactividad#

En la charla mencioné que la métrica INP (Interaction to Next Paint) reemplazará a la métrica FID probablemente en 2024. Ahora ya conocemos el plazo del cambio en Core Web Vitals, será en marzo de 2024.

La nueva métrica nuevamente se ocupa de la velocidad de respuesta de la interfaz al clic (u otras entradas) del usuario. Sus enemigos son, por tanto, consultas "ajax" ejecutadas lentamente o tareas largas en JS que bloquean el motor de renderizado.

He calculado que solo el 17 % de los 100 sitios de comercio electrónico más visitados de Chequia cumplen con esta métrica.

FID es cumplido por el 95 % de los sitios web a nivel mundial ⨉ INP solo por el 66 %. Me temo que esto dolerá un poco a la comunidad de desarrolladores el próximo año, especialmente para sitios construidos con frameworks de JavaScript.

¿Cuáles son las principales diferencias entre las métricas INP y FID?

• FID = primera interacción × INP = toda la estancia en la página. Por lo tanto, no basta con reaccionar rápidamente solo al primer clic. Se cuenta el peor de todos.
• FID = primera parte de la reacción × INP = toda la reacción. FID mide solo el tiempo hasta que el clic comienza a ser procesado por JavaScript. INP espera hasta que la página se repinte en el nuevo estado.

La optimización de la métrica INP en tu sitio web puede llevar tiempo, por lo que recomendamos comenzar a ocuparse de este tema pronto. INP ahora también aparece en nuestro tester de velocidad, incluyendo su monitoreo. Por supuesto, también podemos ayudarte con la optimización de esta métrica.

En los siguientes consejos, pasaremos de tecnologías y métricas a herramientas.

8) Web Vitals overlay, un ayudante discreto pero genial#

Para que los desarrolladores puedan resolver los problemas correctos, deben saber medir las métricas correctamente.

El panel Web Vitals overlay es mucho mejor para pruebas locales que Lighthouse. Muestra las métricas correctas y están calculadas correctamente.

Es importante darse cuenta de que Lighthouse, sin configuraciones especiales, mide de manera sintética y, por lo tanto, no puede medir correctamente las métricas obtenidas del usuario durante toda su estancia en la página.

¿Cómo acceder al Web Vitals overlay?

• Abre las Herramientas de Desarrollador de Chrome (F12).
• Cmd + Shift + P en Mac, o Ctrl + Shift + P en Windows.
• Comienza a escribir "Web Vitals Overlay".

Con métricas como CLS o ahora INP, no obtendrás los mismos números que luego ves en los datos de Google.

Una alternativa razonable al Web Vitals overlay es la extensión Web Vitals.

9) Perf. Insights, nueva herramienta de ajuste de velocidad#

Performance Insights es algo así como la pestaña Performance, pero para personas.

En Insights, Chrome muestra información específica para ajustar métricas específicas, como por ejemplo en CLS:

• Desplazamientos no deseados específicos en CLS (1).
• Puntuación CLS (2).
• Posibles causas del problema (3).

Si necesitas detalles para ajustar la velocidad y la pestaña Performance te resulta demasiado complicada, considera Performance Insights.

10) Trace.Cafe, comparte resultados de mediciones detalladas de velocidad#

Un consejo muy breve para terminar. Trace.cafe te permite compartir el resultado de Trace (pestaña Performance) en una URL específica.

Descarga los datos en JSON, súbelos a Trace.cafe y comparte la URL resultante con tus colegas. Paul Irish, el autor de esta excelente aplicación, dice que tu trace durará tres meses en la URL dada:

Y hemos llegado al final de esta breve guía de novedades sobre velocidad para desarrolladores.

¿Te gustaría recibir más consejos? Cada mes publicamos un boletín, pero también publicamos en LinkedIn, Twitter o Facebook.

Etiquetas:PageSpeed.ONEWeb Performance