Lista de verificación de velocidad web 2021

Hagamos el 2021... rápido. En esta traducción al español, presentamos una lista de verificación para optimizar la velocidad del frontend de los sitios web. Contiene casi todo lo que necesitas saber para asegurar una experiencia de usuario rápida hoy en día, desde métricas hasta herramientas y técnicas de desarrollo.

Esta lista de verificación es una traducción de Front-End Performance Checklist 2021. Gracias a Smashing Magazine.

Contenido del artículo:

1. Preparación: Planificación y métricas
2. Establecimiento de objetivos realistas
3. Definición del entorno de desarrollo
4. Optimización de archivos
5. Optimización de la construcción
6. Optimización de la carga
7. Red y HTTP/2
8. Pruebas y monitoreo
9. Ganancias rápidas

• Cree una “cultura de rendimiento”, una cultura que apoye la velocidad del sitio web.

  La velocidad del sitio web no puede ser sostenida a largo plazo sin inversión. Examine las quejas comunes que llegan al soporte al cliente y descubra cómo aumentar la velocidad puede ayudar a mitigar algunos de estos problemas. Cree un estudio de caso con datos reales y métricas comerciales, adaptado a su empresa. Ya en el diseño del sitio, planifique el proceso de carga del sitio y los posibles compromisos.

• Sea un 20 % más rápido que su competidor más rápido.

  Recopile datos sobre los dispositivos que utilizan los visitantes de su sitio. Priorice dispositivos reales sobre simulaciones. Elija un móvil Moto G4/G5 Plus; un dispositivo Samsung de gama media (Galaxy A50, S8); un buen dispositivo de gama media como Nexus 5X, Xiaomi Mi A3 o Xiaomi Redmi Note 7 y un dispositivo lento como Alcatel 1X o Cubot X19. Alternativamente, puede emular un sistema operativo móvil en una computadora probando con velocidad de red limitada (por ejemplo, 300 ms RTT, 1,6 Mb/s de descarga, 0,8 Mb/s de carga) con CPU limitada (5x ralentización). Luego cambie a 3G estándar, 4G lento (por ejemplo, 170 ms RTT, 9 Mb/s de descarga, 9 Mb/s de carga) y Wi-Fi. Recoja datos, cree una tabla, reste el 20 % de los resultados y establezca sus objetivos (“performance budgets”, límites de velocidad).

• Seleccione las métricas correctas.

  No todas las métricas tienen el mismo valor desde el punto de vista de la optimización. Estudie cuáles son las métricas más importantes: generalmente estarán relacionadas con la rapidez con la que se empiezan a renderizar los píxeles más importantes y qué tan rápida es la respuesta de entrada. Enfóquese en la carga de la página según las prioridades de sus visitantes. Normalmente, importa el Tiempo hasta la interactividad (Time To Interactive – TTI), el Retraso de la primera entrada (First Input Delay – FID), el tiempo de renderizado del elemento “hero”, el Mayor contenido pintado (Largest Contentful Paint – LCP), el Tiempo total de bloqueo (Total Blocking Time – TBT) y el Cambio acumulativo de diseño (Cumulative Layout Shift – CLS). No en: Primer pintado significativo (First Meaningful Paint).

• Configure perfiles de prueba: “limpio” y “de cliente”.

  Desactive los programas antivirus y las tareas que consumen CPU en segundo plano, detenga las transferencias de datos en segundo plano y pruebe con un perfil de usuario “limpio” sin extensiones de navegador para evitar distorsiones en los resultados. Estudie qué extensiones usan sus clientes y pruebe también con un perfil “de cliente” especial.

• Comparta la Lista de verificación de velocidad web con sus colegas.

  Asegúrese de que cada miembro del equipo conozca esta Lista de verificación de velocidad web. Cada decisión impacta el rendimiento y su proyecto se beneficiará notablemente si el control se divide entre todo el equipo. Al mismo tiempo, mapee las decisiones de diseño y contrástelas con el presupuesto de rendimiento.

• Tiempo de respuesta de 100 milisegundos, 60 cuadros por segundo.

  Cada cuadro de animación debe ejecutarse en 16 milisegundos, idealmente 10 milisegundos, alcanzando así los deseados 60 cuadros por segundo (1 segundo ÷ 60 = 16,6 milisegundos). Sea optimista y utilice sabiamente el tiempo de inactividad; para tareas pesadas, como las animaciones, es mejor no hacer nada más en la página. Donde esto no sea posible, haga solo lo absolutamente mínimo. La latencia de entrada estimada debe ser inferior a 50 ms. Utilice el tiempo de inactividad con el enfoque Idle Until Urgent.

• LCP < 2,5 segundos; FID < 100 ms; CLS < 0,1; TTI < 5 segundos en 3G.

  Si considera como dispositivo base un móvil Android con un precio alrededor de 160 EUR en una red 3G lenta, emulado a una velocidad de 400 ms RTT y 400 kB/s, apunte a un tiempo hasta la interacción (TTI) < 5 segundos y a visitas repetidas bajo 2–3 segundos. Enfóquese en el renderizado del mayor contenido < 2,5 segundos y minimice el Tiempo total de bloqueo (TBT) y el Cambio acumulativo de diseño (CLS). Intente reducir estos valores al mínimo.

• Límite de tamaño de archivo < 170 kB.

  Los primeros 14–16 kB de código HTML son los más críticos, ya que es la única parte que se entrega en el primer paquete transferido en la red (“first roundtrip”). Para alcanzar los objetivos establecidos, trabaje con tamaños de archivo con un máximo de 170 kB comprimidos con gzip (0,7 – 0,8 MB descomprimidos). Asegúrese de que sus límites de velocidad cambien según las condiciones de la red y las limitaciones de hardware.

• Elija y configure bien sus herramientas de construcción.

  No se preocupe demasiado por si es una herramienta “cool” o no. Si logra resultados rápidamente y no tiene problemas para mantener su proceso de creación, entonces está bien. Las excepciones pueden ser Webpack o Parcel, que ofrecen técnicas de optimización útiles como la división de código (code-splitting). Si aún no utiliza estas técnicas, eche un vistazo a la división de código y al tree-shaking.

• Utilice el mejoramiento progresivo por defecto (progressive enhancement).

  Primero diseñe y cree una interfaz básica para que el sitio cumpla su función esencial. Luego mejore la interfaz con funciones avanzadas para diferentes navegadores, creando una interfaz robusta y estable para diferentes usuarios con diferentes dispositivos. Si su sitio se ejecuta rápidamente en un dispositivo lento, con una mala pantalla y en un navegador deficiente en una red no óptima, entonces también se ejecutará más rápido en un dispositivo rápido, con un buen navegador y en una red razonablemente rápida.

• Establezca el listón del rendimiento alto.

  JavaScript implica los mayores costos para la experiencia del usuario. Con un límite de 170 kB, que ya incluye datos críticos y rutas – HTML / CSS / JavaScript, enrutador, gestión de estado, herramientas, interfaces y aplicaciones – examine cuidadosamente los costos de tiempo de transferencia de red, análisis, compilación y ejecución del framework.

• Evalúe cada framework y cada dependencia.

  No todos los proyectos necesitan un framework, no todas las aplicaciones de una sola página (SPA) necesitan cargar un framework. Elija con cuidado; evalúe el JS de terceros examinando características, accesibilidad, estabilidad, velocidad, ecosistemas de paquetes, curva de aprendizaje, documentación, herramientas, registros, equipo, compatibilidad y seguridad. Next.js (React), Gatsby (React), Vuepress (Vue) y Preact CLI ofrecen buenos valores predeterminados para cargas rápidas en hardware móvil promedio.

• Elija sabiamente: React, Vue, Angular, Ember y compañía.

  Asegúrese de que el framework que elija ofrezca renderizado del lado del servidor (SSR) o prerenderizado. Antes de decidirse, mida los tiempos de renderizado en dispositivos móviles tanto en el servidor como en el cliente. Es importante conocer los “tornillos y tuercas” del framework en el que confiará. Revise el patrón de diseño PRPL y la arquitectura App Shell. Buenas opciones son Preact, Inferno, Vue, Svelte, Alpine, Polymer.

• Optimice el rendimiento de sus API.

  Una API puede convertirse fácilmente en un cuello de botella cuando es accedida por múltiples servicios al mismo tiempo. Considere el uso de GraphQL, que le permite ejecutar consultas sobre un sistema de tipos que construye sobre sus datos. A diferencia de REST, GraphQL puede obtener todos los datos en una sola consulta, sin descargar demasiado ni demasiado poco, lo cual es común en arquitecturas REST.

• ¿Considerará tecnologías como Google AMP o Facebook Instant Articles?

  Incluso sin estas tecnologías, puede lograr un buen rendimiento, pero AMP ofrece una base de rendimiento muy sólida y una CDN global. Instant Articles lo ayudan a obtener principalmente visibilidad en Facebook y una carga hasta 4 veces más rápida que los sitios móviles normales.

• Elija su CDN sabiamente.

  Considere cuánto depende de datos dinámicos. Al menos una parte de su contenido puede generarse estáticamente, cargarse en una CDN y así evitar consultas innecesarias a la base de datos (JAMStack). Verifique que la CDN realice compresión de contenido y conversión de imágenes (por ejemplo, optimización y cambio de tamaño o formato) y que soporte trabajadores del servidor.

• Utilice Brotli para la compresión.

  Brotli es un nuevo formato de datos sin pérdida, compatible con todos los navegadores modernos. Es más eficiente que GZip y Deflate. La compresión es muy lenta, pero la descompresión es rápida. Precomprime activos estáticos con Brotli y Gzip al nivel más alto, comprima HTML dinámicamente en tiempo de ejecución con Brotli (nivel 1-4). También verifique el soporte de Brotli en su CDN. Asegúrese de que el servidor maneje correctamente la “negociación de contenido” para Brotli o Gzip.

• Utilice imágenes responsivas, AVIF y WebP.

  Siempre que sea posible, utilice imágenes responsivas con propiedades srcset, sizes, <picture> e image-set. Utilice AVIF y WebP con <picture> y JPEG/PNG como respaldo o detecte el soporte mediante el encabezado Accept. Nota: Con WebP reduce el volumen de datos, pero con JPEG puede mejorar la velocidad percibida gracias a la propiedad de “renderizado progresivo”.

• ¿Están las imágenes correctamente optimizadas?

  Use mozJPEG para comprimir JPEG, SVGO para comprimir SVG, Pingo para PNG o Squoosh para todos ellos (incluido AVIF). Para verificar la eficiencia de su marcado responsivo, puede usar la herramienta imaging-heap. Para imágenes críticas, use JPEG progresivo y desenfoque las partes innecesarias (aplicando desenfoque gaussiano) y elimine el contraste (puede restablecerlo usando filtros CSS). Asegúrese de que tiene configurados los atributos width y height para todas sus imágenes. Agregue compresión automática de imágenes a sus pull requests y explore la carga diferida (lazy loading) de imágenes menos críticas.

• ¿Están los videos correctamente optimizados?

  En lugar de GIFs animados, use ya sea WebP animado (y GIF como respaldo) o inserte bucles con video HTML5 en línea. Asegúrese de que sus archivos MP4 estén procesados con codificación multipaso, desenfocados con el efecto “frei0r iirblur” (si está disponible), los metadatos moov atom se muevan a la cabecera del archivo, y su servidor acepte Byte serving. Siempre que sea posible, use video en formato AV1, pero proporcione también respaldo para formatos más antiguos. Ajuste las dimensiones de los videos y, mediante la entrega adaptativa de medios, proporcione contenido que los visitantes puedan reproducir en sus dispositivos sin demoras.

• ¿Están optimizadas las fuentes?

  Configure correctamente el subsetting de las fuentes. Priorice WOFF2 y utilice WOFF como respaldo. Use una fuente de respaldo para mostrar contenido de inmediato, cargue la fuente personalizada de forma asíncrona y luego cambie a la fuente. Solución ideal: renderizado en dos etapas, primero con un súper conjunto pequeño y el resto se carga de forma asíncrona más tarde. Precargue (preload) 1-2 fuentes de cada familia. Evite usar local() en la declaración de fuentes, pero considere usar fuentes instaladas en el sistema operativo. No olvide usar font-display:optional y eventos de carga de fuentes para volver a renderizar. Use métricas Web Font Reflow Count y Time To Real Italics.

• Establezca correctamente las prioridades.

  Revise todos sus recursos (JavaScript, imágenes, fuentes, scripts de terceros, módulos “costosos” en la página) y divídalos en grupos. Defina la experiencia básica (contenido básico completamente accesible para navegadores más antiguos), la experiencia mejorada (enriquecida, completa para navegadores modernos) y los complementos (recursos que no son absolutamente necesarios y que pueden cargarse de forma diferida).

• Utilice módulos JavaScript nativos en producción.

  En navegadores más antiguos, soporte la experiencia básica, solo completa en navegadores modernos. Para cargar JavaScript use ES2017+ <script type="module">. Los navegadores modernos interpretan el script como un módulo JavaScript y lo ejecutan según lo esperado. Los navegadores más antiguos lo ignoran.

• La ejecución de JavaScript es costosa, así que domínela.

  En aplicaciones SPA, necesita tiempo para inicializar la aplicación antes de poder renderizar la página. Busque módulos y técnicas para acelerar el tiempo de renderizado inicial, como progressive hydration e importación al interactuar (en móviles antiguos los tiempos son 2-5x más altos).

• Use tree-shaking, scope hoisting y code-splitting para reducir la carga.

  Tree-shaking es un método que utiliza solo el código realmente usado al construir. Code-splitting divide el código en “bloques” que se cargan bajo demanda. Scope hoisting detecta dónde se pueden fusionar importaciones y convertirlas en funciones en línea manteniendo la funcionalidad (por ejemplo, con Webpack). Use granular chunking y mueva parte del renderizado del cliente al servidor. Defina la división observando qué bloques CSS/JS se usan y cuáles no. También considere la división de código a nivel de paquete.

• ¿Puede mover JavaScript a Web Worker o WebAssembly?

  A medida que el código evoluciona, comienzan a aparecer puntos débiles en el rendimiento del entorno de usuario. Es común que las operaciones con el DOM se ejecuten junto con su JS en el hilo principal. Considere mover estas operaciones costosas a procesos en segundo plano que se ejecutan en un hilo diferente usando webworkers. Caso típico: precarga de datos a PWA. Considere mover tareas computacionalmente intensivas a WebAssembly, que funciona mejor para aplicaciones web exigentes, como juegos.

• Envíe código para navegadores antiguos solo a esos navegadores antiguos.

  Use babel-preset-env para transpilar funciones ES2017+ no compatibles con los navegadores modernos que usted apoya. Luego configure dos versiones de compilación, una para navegadores modernos y otra para navegadores más antiguos.

  Para lodash, use babel-plugin-lodash, que carga solo los módulos que usted usa en el código fuente. Cambie el require general de lodash y seleccione solo los utilizados, evitando duplicación de código. Utilice <link rel="modulepreload"> para iniciar la carga anticipada (de alta prioridad) de módulos.

• Identifique y reescriba el código antiguo (legacy) con “incremental decoupling”.

  Revise las dependencias del proyecto y evalúe cuánto tiempo se necesitaría para refactorizar o reescribir el código antiguo. Primero configure métricas que rastreen si la proporción de llamadas al código legacy permanece igual o disminuye. La proporción no debe aumentar. Establezca en el equipo tales condiciones que no toleren el uso de bibliotecas adicionales y asegúrese de que CI siempre alerte a los desarrolladores durante el pull request.

• Identifique y elimine CSS/JavaScript no utilizados.

  La cobertura de CSS y JavaScript en el navegador Chrome le permite ver qué código se ha ejecutado/usado y cuál no. Una vez que asegure el código no utilizado, encuentre estos módulos y agregue carga diferida usando import(). Después de ajustar, repita la prueba de cobertura de código y verifique que ahora se envíe menos código en la primera carga. Use Puppeteer para recopilar automáticamente los resultados de cobertura de código.

• Reduzca el tamaño de las dependencias en JavaScript.

  Es muy probable que en sus proyectos tenga bibliotecas JavaScript completas, pero realmente use solo una fracción del código. Considere usar webpack-libs-optimizations, que elimina métodos y polyfills no utilizados durante el proceso de construcción. Agregue a su flujo de trabajo habitual la verificación de paquetes. Bundlephobia ayuda a cuantificar el impacto en el rendimiento al agregar paquetes individuales de NPM al proyecto. Size-limit extiende la verificación clásica del tamaño del paquete al tiempo de ejecución en JavaScript. Skypack se puede usar como fuente de paquetes enfocados en la calidad y el rendimiento, gestionados por miembros individuales de la comunidad.

• ¿Está usando prefetch predictivo para fragmentos de código JavaScript?

  Use su experiencia e intuición para determinar cuándo precargar su JS. Guess.js incluye herramientas que utilizan datos de Google Analytics para determinar qué página es probable que el usuario visite a continuación. Considere Quicklink, Instant.page y DNStradamus. Nota: Posiblemente esté dando instrucciones al navegador para que descargue datos innecesarios y precargue páginas innecesarias. Definitivamente recomendamos ser cauteloso en cuanto al número de solicitudes precargadas.

• Optimice para sus motores de JavaScript objetivo.

  Use script streaming para scripts monolíticos para que puedan analizarse tan pronto como comience la descarga en un hilo separado en segundo plano. También implemente code caching para el motor V8 separando bibliotecas del código que las usa. Considere también estrategias de optimización JIT para el Baseline Interpreter del navegador Firefox.

• Encuentre una forma de combinar el renderizado del lado del cliente y del servidor.

  Generalmente, el objetivo es encontrar un equilibrio óptimo entre el renderizado del lado del cliente y del servidor. Considere el prerenderizado si sus páginas no cambian demasiado a menudo y, si es posible, retrase el arranque de frameworks. Transmita fragmentos (chunks) de HTML mediante renderizado del lado del servidor e hidrátelos al mostrar, interactuar o durante la inactividad, para obtener lo mejor de ambos mundos. (Streaming Server-Side Rendering With Progressive Hydration).

• Considere microoptimizaciones y arranque progresivo.

  Use renderizado del lado del servidor para un “primer pintado significativo” (FMP) rápido, pero también incluya el mínimo JS para mantener el “tiempo hasta la interacción” (TTI) cerca del “primer pintado significativo”. Luego, ya sea bajo demanda o cuando el tiempo lo permita, ejecute partes no esenciales de la aplicación. Siempre divida la ejecución de funciones en tareas asíncronas. Si es posible, use requestIdleCallback.

• Aloje usted mismo recursos de terceros.

  El uso de una CDN pública no es automáticamente más rápido. Incluso si dos sitios enlazan la misma URL de recurso de terceros, el código se descarga nuevamente para cada dominio. El caché es aislado por dominio. Los recursos propios se mantienen en caché con mayor probabilidad que los recursos de terceros. El alojamiento propio es más confiable, seguro y eficiente.

• Limite el impacto de los scripts de terceros.

  Con demasiada frecuencia, un script de terceros hará esa “cola larga” y arruinará la velocidad. Considere usar service workers para descargar recursos con un límite de tiempo. Establezca una Política de Seguridad de Contenidos (CSP) para limitar el impacto de los scripts de terceros, como prohibir la descarga de audio o video. Inserte scripts a través de un iframe, de modo que los scripts no tengan acceso al DOM. Explore las pruebas de carga de scripts en la pestaña Performance (DevTools). Cargue scripts de terceros solo después de que la aplicación se haya cargado. Concéntrese en fragmentos de código que impidan el parpadeo del contenido antes de que se cargue el script.

• Configure correctamente las cabeceras de caché HTTP.

  Verifique si expires, cache-control, max-age y otras cabeceras de caché HTTP están configuradas correctamente. En general, los recursos deben ser cacheables por un tiempo muy corto (si es probable que cambien) o indefinidamente (si son estáticos).

  Use cache-control: immutable para evitar la revalidación. Asegúrese de no enviar cabeceras innecesarias (por ejemplo, x-powered-by, pragma, x-ua-compatible, expires). Aproveche el cero RTT para re-renderización a través de stale-while-revalidate.

• Cargue JavaScript de forma asíncrona.

  Aproveche la carga diferida para todos los componentes como archivos JS grandes, videos, iframes, widgets y también imágenes. Utilice lazy-loading nativo (atributos loading e importance), o usando una solución basada en Intersection Observer. La segunda solución también puede usarse para un poderoso “scrollytelling” - efecto tipo parallax, o seguimiento de anuncios.

• Retrase el renderizado y la decodificación de imágenes grandes.

  Con la propiedad content-visibility: auto podemos instruir al navegador para que omita el renderizado de los descendientes de un elemento determinado si dicho elemento está fuera del viewport. Asegúrese de usar la propiedad contain-intrinsic-size con un placeholder adecuadamente elegido para evitar la degradación de la métrica de Desplazamiento Acumulativo de Diseño (CLS). Utilice también <img decoding="async">. El navegador luego decodificará la imagen fuera del hilo principal y se reducirá el tiempo de CPU necesario para la operación.

• Cargue lo más rápido posible el CSS crítico.

  Extraiga del CSS todos los estilos necesarios para renderizar el contenido visible en la página en el viewport (también conocido como CSS crítico o CSS por encima de la línea de flotación). Agregue estos estilos como inline en la etiqueta <head> de la página. La regla de oro es que no debe superar un tamaño total de 14 kB. Considere la inclusión condicional de CSS en la página. En algunos casos, puede ser más rentable insertar el CSS crítico en un archivo separado en la raíz del dominio. Gracias al caché, esta solución puede ser mejor que insertar estilos inline.

• Experimente con la reorganización de archivos/propiedades CSS.

  Al optimizar la carga, también puede considerar dividir el CSS principal según las consultas de medios individuales. No coloque <link rel ="stylesheet"/> antes de los archivos asíncronos. Si los scripts no dependen de los estilos, considere colocar los scripts bloqueadores sobre los estilos bloqueadores. Si lo hacen, divida este JavaScript en dos y cárguelo antes y después de los archivos CSS. Almacene en caché el CSS inline usando service workers y experimente con CSS en el cuerpo. Los estilos dinámicos pueden ser “costosos”: verifique si el CSS-in-JS optimiza la ejecución, si el CSS no tiene dependencias de apariencia o propiedades de componentes, no complique los componentes (styled-components).

• Transmita las respuestas.

  Transmisión proporciona una interfaz para leer o escribir bloques de datos asíncronos, cuyo subconjunto puede estar disponible en memoria en un momento dado. En lugar de servir un esqueleto de UI vacío y llenar el contenido con JavaScript, use un service worker, cargue el esqueleto desde el caché y el contenido desde la red. El HTML renderizado durante la solicitud inicial puede luego aprovechar al máximo el analizador HTML del navegador.

• Considere adaptar sus componentes a la conexión y memoria del dispositivo.

  Use la cabecera client-hint Save-Data y adapte la aplicación a las limitaciones de sus usuarios (costo, rendimiento). Puede sobrescribir solicitudes de imágenes de alta DPI a bajas DPI, eliminar fuentes web, parallax, desactivar la reproducción automática de videos o incluso cambiar la forma en que entrega el código. Use Network Information API para entregar variantes de componentes exigentes en función de la conexión y Device Memory API para adaptar recursos según la memoria del dispositivo.

• Mantenga una conexión persistente para acelerar la entrega.

  Ahorre tiempo utilizando resource hints; dns-prefetch (búsqueda DNS en segundo plano), preconnect (inicia el handshake de conexión (DNS, TCP, TLS)), prefetch (solicitud de recursos), preload (precarga recursos sin ejecutarlos) y prerender (carga recursos previamente sin ejecutar JS y sin renderizado en la página). Al usar preload, se debe definir as, o no se cargará nada. Precargar fuentes sin el atributo crossorigin causará una doble carga. Al usar preload existen varias prioridades, así que considere insertar elementos rel=”preload” en el DOM justo antes de los scripts bloqueadores externos.

• Use service workers para almacenamiento en caché y como respaldo en caso de fallo de red.

  Si su sitio está en HTTPS, almacene recursos estáticos en el caché de service worker y guarde un respaldo offline (o incluso páginas completas) y cárguelos desde el dispositivo en lugar de la red. Almacene el entorno de la aplicación en el caché de service worker junto con algunas páginas críticas, por ejemplo, una página offline o la página de inicio. Pero asegúrese de que haya una cabecera CORS adecuada en la respuesta, no almacene respuestas opacas y registre imágenes de origen cruzado en modo CORS.

• Use service worker en CDN/Edge (por ejemplo, para pruebas A/B).

  En una CDN que implemente service workers en el servidor, considere ajustar el rendimiento usando service workers directamente “en el borde”. Por ejemplo, en pruebas A/B, cuando se necesita cambiar el contenido de HTML para diferentes usuarios, use service worker en la CDN para procesar la lógica.

  Acelere los sitios que utilizan fuentes de Google mediante stream HTML rewriting.

• Optimice el rendimiento de renderizado.

  Si es necesario, aísle componentes costosos mediante CSS containment. Asegúrese de que al desplazarse por la página o animar un elemento no haya demoras y que constantemente alcance una velocidad de 60 cuadros por segundo. Si no es posible, trate de mantener la velocidad de cuadros al menos constante. La velocidad mínima de repintado generalmente se considera 15 cuadros por segundo. Use CSS will-change para informar al navegador sobre qué elementos cambiarán.

• ¿Tiene una experiencia de renderizado optimizada?

  No subestime el papel de la velocidad percibida. Si está cargando archivos, intente siempre estar un paso adelante del cliente para que la experiencia sea fluida, incluso si hay muchas cosas sucediendo en segundo plano. Para atraer al cliente, use “skeletons” en lugar de ruedas de carga y agregue transiciones y animaciones.

• Evite los cambios de diseño (reflow) y repintado (repaint).

  Los cambios de diseño son comúnmente causados por el cambio de tamaño de componentes como videos e imágenes, además de la carga de fuentes web, anuncios insertados o la carga de contenido real en componentes. Establezca width y height para imágenes para que los navegadores modernos puedan reservar el espacio necesario. Use SVG como marcador de posición para reservar suficiente espacio donde aparecerán imágenes o videos. Use carga diferida de JavaScript si no hay una versión nativa disponible para el componente. Cargue JS diferido solo cuando realmente lo necesite. Identifique cambios de diseño causados por fuentes web y compare line-height y espacios con font-style-matcher. Monitoree la estabilidad del diseño con el API de inestabilidad de diseño y la métrica de Cambio Acumulativo de Diseño (CLS).

• ¿Tiene habilitado el OCSP stapling?

  OCSP stapling puede acelerar el proceso de autenticación TLS, ya que el navegador no necesita perder tiempo buscando y descargando información sobre el certificado de su dominio.

• ¿Ha reducido el impacto de la revocación del certificado SSL?

  Los certificados de Extended Validation (EV) son costosos y requieren tiempo, ya que siempre deben ser verificados por un humano. Los certificados de Validación de Dominio (DV) son gratuitos (Let’s Encrypt) y su obtención y renovación pueden automatizarse fácilmente. Los certificados EV además no soportan OCSP stapling, por lo que siempre debe tener un certificado DV con el stapling habilitado.

• ¿Está usando IPv6?

  Estudios muestran que los sitios web son hasta un 15 % más rápidos gracias al NDP (Neighbor Discovery Protocol) y la optimización de rutas. Actualice sus registros DNS para que su sitio sea accesible también a través de IPv6. Sin embargo, no olvide el IPv4 existente, ya que ambas versiones no son compatibles entre sí.

• ¿Está utilizando TCP BBR?

  BBR es un algoritmo de control de flujo TCP relativamente nuevo. Responde más al verdadero congestionamiento que a la pérdida de paquetes, como hace TCP. Como tal, es significativamente más rápido, con mayor rendimiento y menor latencia. Habilite BBR y configure tcp_notsent_lowat a 16 kB para que la priorización en HTTP/2 funcione confiablemente en núcleos Linux 4.9 y superiores.

• Priorice siempre HTTP/2.

  HTTP/2 está muy bien soportado y ofrece un aumento de velocidad. Dependiendo de cuán grande sea su base de usuarios móviles, es posible que necesite enviar diferentes build (compilaciones de la aplicación) a los usuarios y pueda beneficiarse de adaptar diferentes build para diferentes dispositivos. (HTTP/2 es a menudo más lento en redes con una pérdida de paquetes notable).

• Despliegue HTTP/2 correctamente.

  Debe encontrar un equilibrio delicado entre combinar módulos en uno y cargar muchos módulos pequeños en paralelo. Divida toda su interfaz en muchos módulos pequeños; luego agrúpelos, comprímalos y conviértalos en paquetes. Divídalos a nivel de paquete o según el monitoreo de bloques CSS/JS no utilizados. Separe el código de terceros del suyo propio y separe dependencias que cambian rara vez de las que cambian a menudo. Enviar aproximadamente 6–10 paquetes de elementos de frontend parece un buen compromiso (y no está mal para navegadores más antiguos). Experimente y mida para encontrar el equilibrio correcto. Trate de enviar la mayor cantidad de elementos posible a través de una única conexión HTTP/2.

• ¿Sus servidores y CDN soportan HTTP/2?

  Diferentes servidores y CDN soportan HTTP/2 de manera diferente. Usando herramientas que comparan CDNs (por ejemplo, CDN Comparison), puede verificar sus opciones o buscar rápidamente el nivel de soporte para diferentes características. Habilite BBR, configure tcp_notsent_lowat a 16 kB para la priorización en HTTP/2.

• ¿Está utilizando compresión HPACK?

  Si está usando HTTP/2, verifique que sus servidores implementen compresión HPACK para las cabeceras de respuesta HTTP, para reducir la sobrecarga innecesaria. Los servidores HTTP/2 son relativamente nuevos y pueden no soportar completamente la especificación, siendo HPACK un ejemplo. H2spec es una gran herramienta (aunque técnicamente demasiado detallada) que puede verificar esto.

• Prepárese para HTTP/3.

  En HTTP/2, una conexión es compartida por múltiples solicitudes. En HTTP/3, las solicitudes también comparten una conexión, pero se transmiten de manera independiente, por lo que un paquete perdido ya no afecta a todas las solicitudes, solo a un flujo. Con QUIC en HTTP/3, TCP y TLS se combinan y se realizan en un solo viaje de ida y vuelta. Desde la segunda conexión, ya podemos enviar y recibir datos de la capa de aplicación en el primer viaje de ida y vuelta (0-RTT). Todavía importa empaquetar elementos de frontend, así que en lugar de enviar JS monolítico, envíe más archivos JS en paralelo, como en HTTP/2. Espere que HTTP/3 impacte los tiempos de carga en dispositivos móviles.

• ¿Sus servidores y CDN soportan HTTP/3?

  QUIC y HTTP/3 son mejores y más robustos: con handshakes más rápidos, mejor cifrado, flujos independientes más confiables, más cifrados y con 0-RTT si el cliente ya tenía una conexión con el servidor. Sin embargo, es bastante exigente para la CPU (2–3 veces el uso de CPU para el mismo ancho de banda). Verifique si sus servidores o CDN soportan el protocolo HTTP sobre QUIC (también conocido como HTTP/3) y si puede, habilítelo.

• Verifique que la seguridad de su servidor sea inexpugnable.

  Asegúrese de que las cabeceras de seguridad estén configuradas correctamente, elimine vulnerabilidades de seguridad conocidas y verifique la configuración de HTTPS. Asegúrese de que todos los complementos externos y scripts de seguimiento se carguen a través de HTTPS, que no sea posible el scripting entre sitios y que las cabeceras HTTP Strict Transport Security y Content Security Policy estén configuradas correctamente.

• Monitoree las advertencias de contenido mixto (mixed-content).

  Si ha migrado recientemente de HTTP a HTTPS, no olvide monitorear las advertencias de contenido mixto activas y pasivas usando herramientas como Report-URI.io. También puede usar Mixed Content Scan para escanear contenido mixto en su sitio web compatible con HTTPS.

• ¿Ha optimizado su flujo de trabajo de auditoría y depuración?

  Invierta tiempo en estudiar técnicas de depuración y auditoría en su depurador, WebPageTest, Lighthouse y amplíe su editor de texto. Por ejemplo, puede ejecutar WebPageTest desde una hoja de cálculo de Google e integrar las puntuaciones de accesibilidad, rendimiento y SEO en su configuración de Travis usando Lighthouse CI o directamente en Webpack. Para verificaciones rápidas, use CSS Perf Diagnostic.

• ¿Ha probado en navegadores proxy y navegadores más antiguos?

  Probar en Chrome y Firefox no es suficiente. Vea cómo funciona su sitio en navegadores proxy y navegadores más antiguos (incluyendo UC Browser y Opera Mini). Mida la velocidad promedio de Internet entre su base de usuarios para evitar sorpresas. Pruebe con limitaciones de red y emule dispositivos de alta DPI. BrowserStack es fantástico, pero también pruebe en dispositivos reales.

• ¿Ha probado la velocidad de sus páginas 404?

  Cada vez que un cliente solicita un elemento de sitio web que no existe, recibe una respuesta 404, y esta respuesta suele ser enorme. No olvide explorar y optimizar la estrategia de caché también para sus páginas 404. Asegúrese de que el navegador solo muestre HTML si espera una respuesta HTML, y para todas las demás respuestas, devuelva una respuesta de error.

• ¿Ha probado el impacto en el rendimiento de sus consentimientos de GDPR y barras de cookies?

  Normalmente, los consentimientos de cookies no deberían impactar en el CLS, pero a veces puede suceder, así que considere usar recursos gratuitos y de código abierto como Osano o cookie-consent-box. El consentimiento probablemente cambiará el impacto de los scripts en el rendimiento general, por lo que configure y estudie varios perfiles de prueba de rendimiento web para diferentes tipos de consentimiento.

• ¿Ha probado el impacto en la accesibilidad?

  Las páginas grandes y la manipulación del DOM con JavaScript causan retrasos en las notificaciones de lectores de pantalla. Un rápido Time to Interactive significa cuánto tiempo pasa antes de que el lector de pantalla pueda anunciar la navegación en esa página y el usuario del lector de pantalla pueda realmente presionar el teclado para interactuar.

• ¿Está configurado el monitoreo continuo?

  Buenas métricas de velocidad surgen de la combinación de herramientas de monitoreo pasivo y activo. Una instancia privada de WebPageTest y el uso de Lighthouse siempre son ventajosos para pruebas rápidas, pero también configure un monitoreo continuo mediante herramientas RUM, como SpeedTracker, SpeedCurve y otras. Configure sus propias marcas de tiempo de usuario (user-timing marks) para medir y monitorear métricas específicas de su sitio web.

La lista de verificación de velocidad web es bastante compleja y completar todas las optimizaciones puede llevar tiempo. Entonces, si solo tuviera 1 hora para obtener mejoras significativas, ¿qué haría? Lo reducimos todo a 18 frutos al alcance de la mano. Por supuesto, antes de comenzar y una vez que haya terminado, mida los resultados, incluidas las métricas Largest Contentful Paint y Time To Interactive en 3G y también en conexión por cable.

• Mida la velocidad entre usuarios reales y establezca objetivos apropiados. Intente ser al menos un 20 % más rápido que su competidor más rápido. Mantenga el Largest Contentful Paint por debajo de 2,5 s, el First Input Delay por debajo de 100 ms, el Time to Interactive por debajo de 5 segundos en 3G lento, para visitas repetidas por debajo de 2 s. Optimice al menos para el First Contentful Paint y el Time To Interactive.
• Optimice imágenes usando Squoosh, mozjpeg, guetzli, pingo y SVGOMG y sirva AVIF/WebP con un CDN de imágenes.
• Prepare CSS crítico para sus plantillas principales e insértelo inline en <head> de cada una de ellas. Para CSS y JS, tenga un presupuesto para el tamaño de archivos críticos de máx. 170 kB comprimido con gzip (0,7 MB descomprimido).
• Recorte, optimice, posponga y cargue scripts de manera diferida. Invierta en la configuración de su empaquetador para eliminar redundancias y busque alternativas menos voluminosas en datos.
• Aloje siempre archivos frontend estáticos en su propio dominio. También prefiera alojar componentes de terceros en su propio dominio. Limite su impacto. Use fachadas y marcadores de posición, cargue widgets al interactuar y tenga cuidado con el parpadeo de la versión original.
• Sea exigente al elegir un framework. En aplicaciones de una sola página (SPA), identifique las páginas críticas y rendérizelas estáticamente, o al menos pré-rendérizelas. Use hidratación progresiva a nivel de componentes e importe módulos al interactuar.
• El renderizado solo del lado del cliente no es una buena opción para el rendimiento. Pré-renderice si sus páginas no cambian mucho, y posponga el arranque de frameworks. Use renderizado en flujo del lado del servidor (SSR).
• Proporcione código legacy solo a navegadores antiguos utilizando el patrón de diseño module/nomodule.
• Experimente con la reorganización de reglas CSS y pruebe CSS servido directamente en HTML.
• Agregue consejos de recursos (resource hints) para acelerar el servicio usando dns-lookup, preconnect, prefetch, preload, prerender.
• Subsetee fuentes web y cárguelas asíncronamente, utilice font-display en CSS para un renderizado rápido.
• Verifique que las cachés HTTP y las cabeceras de seguridad estén configuradas correctamente.
• Habilite la compresión Brotli en el servidor. (Si no es posible, no olvide habilitar la compresión Gzip).
• Habilite el control de flujo TCP con BBR, si su servidor se ejecuta en un kernel de Linux versión 4.9+.
• Si es posible, habilite OCSP stapling e IPv6. Siempre sirva un certificado DV con OCSP.
• Habilite la compresión HPACK para HTTP/2 y migre a HTTP/3 si está disponible.
• Cachee elementos como fuentes, estilos, JavaScript e imágenes en la caché de Service Worker.
• Explore maneras de evitar la rehidratación, use hidratación progresiva y renderizado en flujo del lado del servidor para su aplicación de una sola página (SPA).

Muchas gracias por la revisión del artículo original en Smashing Magazine a Guy Podjarny, Yoav Weiss, Addy Osmani, Artem Denysov, Denys Mishunov, Ilya Pukhalski, Jeremy Wagner, Colin Bendell, Mark Zeman, Patrick Meenan, Leonardo Losoviz, Andy Davies, Rachel Andrew, Anselm Hannemann, Barry Pollard, Patrick Hamann, Gideon Pyzer, Andy Davies, Maria Prosvernina, Tim Kadlec, Rey Bango, Matthias Ott, Peter Bowyer, Phil Walton, Mariana Peralta, Pepijn Senders, Mark Nottingham, Jean Pierre Vincent, Philipp Tellis, Ryan Townsend, Ingrid Bergman, Mohamed Hussain S. H., Jacob Groß, Tim Swalling, Bob Visser, Kev Adamson, Adir Amsalem, Aleksey Kulikov y Rodney Rehm.

Traducción al español: Tomáš Hejč, Martin Brychta, Zuzana Fatrdla, Martin Michálek. (Equipo PageSpeed.ONE)

Etiquetas:Web Performance