Lista de verificación de rendimiento de front-end 2021 (PDF, Apple Pages, MS Word)

 

 

 


Índice
  1. Tabla de contenido
  2. Preparándose: planificación y métricas

Hagamos que el 2021… ¡rápido! Una lista de verificación anual del rendimiento del front-end (disponible como PDF , Apple Pages , MS Word ), con todo lo que necesita saber para crear experiencias rápidas en la web hoy en día, desde métricas hasta herramientas y técnicas de front-end. Actualizado desde 2016. Ah, también puede obtener consejos útiles sobre el front-end en nuestro boletín informativo por correo electrónico .

 

Esta guía ha contado con el amable apoyo de nuestros amigos de LogRocket , un servicio que combina monitoreo del rendimiento del frontend , reproducción de sesiones y análisis de productos para ayudarlo a crear mejores experiencias para los clientes. LogRocket rastrea métricas clave, incl. DOM completo, tiempo hasta el primer byte, retraso de la primera entrada, CPU del cliente y uso de memoria. Obtenga una prueba gratuita de LogRocket hoy.

El rendimiento web es complicado, ¿no? ¿Cómo sabemos realmente dónde nos encontramos en términos de desempeño y cuáles son exactamente nuestros cuellos de botella en el desempeño? ¿Es JavaScript caro, entrega lenta de fuentes web, imágenes pesadas o renderizado lento? ¿Hemos optimizado lo suficiente con la sacudida de árboles, la elevación del alcance, la división de código y todos los patrones de carga sofisticados con observador de intersecciones, hidratación progresiva, sugerencias de clientes, HTTP/3, trabajadores de servicios y, Dios mío, trabajadores de borde? Y, lo más importante, ¿ por dónde empezamos a mejorar el rendimiento y cómo establecemos una cultura de rendimiento a largo plazo?

En el pasado, el rendimiento era a menudo una mera idea de último momento . A menudo pospuesto hasta el final del proyecto, se reduciría a minificación, concatenación, optimización de activos y potencialmente algunos ajustes finos en el configarchivo del servidor. Ahora, mirando hacia atrás, las cosas parecen haber cambiado de manera bastante significativa.

El rendimiento no es sólo una preocupación técnica: afecta todo, desde la accesibilidad hasta la usabilidad y la optimización de los motores de búsqueda, y al integrarlo en el flujo de trabajo, las decisiones de diseño deben basarse en sus implicaciones en el rendimiento. El rendimiento debe medirse, monitorearse y perfeccionarse continuamente , y la creciente complejidad de la web plantea nuevos desafíos que dificultan el seguimiento de las métricas, porque los datos variarán significativamente según el dispositivo, el navegador, el protocolo, el tipo de red y la latencia ( Las CDN, los ISP, las cachés, los proxies, los firewalls, los equilibradores de carga y los servidores desempeñan un papel en el rendimiento).

Entonces, si creáramos una descripción general de todas las cosas que debemos tener en cuenta al mejorar el rendimiento, desde el inicio del proyecto hasta el lanzamiento final del sitio web, ¿cómo sería? A continuación encontrará una lista de verificación de rendimiento de front-end (con suerte, imparcial y objetiva) para 2021 : una descripción general actualizada de los problemas que podría necesitar considerar para garantizar que sus tiempos de respuesta sean rápidos, la interacción del usuario sea fluida y sus sitios no drenar el ancho de banda del usuario.

 

Tabla de contenido

  • Todo en páginas separadas
  • Preparándose: planificación y métricas
    Cultura de rendimiento, Core Web Vitals, perfiles de rendimiento, CrUX, Lighthouse, FID, TTI, CLS, dispositivos.
  • Establecimiento de objetivos realistas
    Presupuestos de rendimiento, objetivos de rendimiento, marco RAIL, presupuestos de 170 KB/30 KB.
  • Definir el entorno
    Elegir un marco, costo de rendimiento básico, Webpack, dependencias, CDN, arquitectura front-end, CSR, SSR, CSR + SSR, renderizado estático, prerenderizado, patrón PRPL.
  • Optimizaciones de activos
    Brotli, AVIF, WebP, imágenes responsivas, AV1, carga de medios adaptativa, compresión de video, fuentes web, fuentes de Google.
  • Optimizaciones de compilación
    Módulos de JavaScript, patrón de módulo/no módulo, agitación de árboles, división de código, elevación de alcance, Webpack, servicio diferencial, trabajador web, WebAssembly, paquetes de JavaScript, React, SPA, hidratación parcial, importación en interacción, terceros, cache.
  • Optimizaciones de entrega
    Carga diferida, observador de intersecciones, aplazar la representación y decodificación, CSS crítico, transmisión, sugerencias de recursos, cambios de diseño, trabajador de servicio.
  • Redes, HTTP/2,
    grapado HTTP/3 OCSP, certificados EV/DV, empaquetado, IPv6, QUIC, HTTP/3.
  • Pruebas y monitoreo
    Flujo de trabajo de auditoría, navegadores proxy, página 404, solicitudes de consentimiento de cookies GDPR, CSS de diagnóstico de rendimiento, accesibilidad.
  • Triunfos rápidos
  • Descargue la lista de verificación (PDF, Apple Pages, MS Word)
  • ¡Vamos!

(También puede descargar la lista de verificación en PDF (166 KB) o descargar el archivo editable de Apple Pages (275 KB) o el archivo .docx (151 KB). ¡Feliz optimización a todos!)

Preparándose: planificación y métricas

Las microoptimizaciones son excelentes para mantener el rendimiento encaminado, pero es fundamental tener objetivos claramente definidos en mente: objetivos mensurables que influirían en cualquier decisión que se tome a lo largo del proceso. Hay un par de modelos diferentes, y los que se analizan a continuación son bastante obstinados; solo asegúrese de establecer sus propias prioridades desde el principio.

  1. Establecer una cultura de desempeño.
    En muchas organizaciones, los desarrolladores front-end saben exactamente cuáles son los problemas subyacentes comunes y qué estrategias se deben utilizar para solucionarlos. Sin embargo, mientras no exista un respaldo establecido a la cultura del desempeño, cada decisión se convertirá en un campo de batalla de departamentos, dividiendo la organización en silos. Necesita la aceptación de las partes interesadas del negocio y, para obtenerla, debe establecer un estudio de caso o una prueba de concepto sobre cómo la velocidad (especialmente Core Web Vitals , que cubriremos en detalle más adelante) beneficia las métricas y los indicadores clave de rendimiento. ( KPI ) que les interesan.

    Por ejemplo, para hacer que el rendimiento sea más tangible, podría exponer el impacto en el rendimiento de los ingresos mostrando la correlación entre la tasa de conversión y el tiempo hasta la carga de la aplicación, así como el rendimiento de renderizado. O la tasa de rastreo del robot de búsqueda (PDF, páginas 27 a 50).

     

    Sin una fuerte alineación entre los equipos de desarrollo/diseño y negocios/marketing, el rendimiento no se mantendrá a largo plazo. Estudie las quejas comunes que llegan al equipo de ventas y servicio al cliente, estudie análisis para detectar altas tasas de rebote y caídas de conversión. Explore cómo mejorar el rendimiento puede ayudar a aliviar algunos de estos problemas comunes. Ajuste el argumento según el grupo de partes interesadas con el que esté hablando.

    Ejecute experimentos de rendimiento y mida los resultados, tanto en dispositivos móviles como en computadoras de escritorio (por ejemplo, con Google Analytics ). Le ayudará a crear un estudio de caso personalizado para la empresa con datos reales. Además, el uso de datos de estudios de casos y experimentos publicados en WPO Stats ayudará a aumentar la sensibilidad de las empresas sobre por qué es importante el rendimiento y qué impacto tiene en la experiencia del usuario y las métricas comerciales. Sin embargo, afirmar que el rendimiento importa por sí solo no es suficiente: también es necesario establecer algunos objetivos mensurables y rastreables y observarlos a lo largo del tiempo.

    ¿Cómo llegar allá? En su charla sobre Creación de rendimiento a largo plazo , Allison McKnight comparte un estudio de caso completo sobre cómo ayudó a establecer una cultura de rendimiento en Etsy ( diapositivas ). Más recientemente, Tammy Everts ha hablado sobre los hábitos de los equipos de desempeño altamente efectivos en organizaciones grandes y pequeñas.

    Al tener estas conversaciones en las organizaciones, es importante tener en cuenta que, así como la UX es un espectro de experiencias, el rendimiento web es una distribución . Como señaló Karolina Szczur , "esperar que un único número pueda proporcionar una calificación a la que aspirar es una suposición errónea". Por lo tanto, los objetivos de desempeño deben ser granulares, rastreables y tangibles.

En dispositivos móviles, por sesión, los usuarios que experimentaron tiempos de carga rápidos generan un 17% más de ingresos que el promedio. ( Impacto del rendimiento web , a través de Addy Osmani )
Esperar que un solo número pueda proporcionar una calificación a la que aspirar es una suposición errónea. (Crédito de la imagen: Performance es una distribución a través de Karolina Czczur )

  1. Objetivo: ser al menos un 20 % más rápido que tu competidor más rápido.
    Según una investigación psicológica , si desea que los usuarios sientan que su sitio web es más rápido que el sitio web de su competencia, debe ser al menos un 20% más rápido. Estudie a sus principales competidores, recopile métricas sobre su desempeño en dispositivos móviles y de escritorio y establezca umbrales que lo ayudarán a superarlos. Sin embargo, para obtener resultados y objetivos precisos, primero asegúrese de obtener una imagen completa de la experiencia de sus usuarios estudiando sus análisis. Luego puede imitar la experiencia del percentil 90 para realizar las pruebas.

    Para obtener una buena primera impresión de cómo se desempeñan sus competidores, puede utilizar Chrome UX Report ( CrUX , un conjunto de datos de RUM listo para usar, introducción en video de Ilya Grigorik y guía detallada de Rick Viscomi), o Treo , una herramienta de monitoreo de RUM que funciona con Chrome UX Report. Los datos se recopilan de los usuarios del navegador Chrome, por lo que los informes serán específicos de Chrome, pero le brindarán una distribución bastante completa del rendimiento, lo más importante, las puntuaciones de Core Web Vitals, entre una amplia gama de visitantes. Tenga en cuenta que los nuevos conjuntos de datos de CrUX se publican el segundo martes de cada mes .

     

    Alternativamente, también puedes usar:

    • Herramienta de comparación de informes Chrome UX de Addy Osmani ,
    • Speed ​​Scorecard (también proporciona un estimador de impacto en los ingresos),
    • Comparación de pruebas de experiencia de usuario real o
    • SiteSpeed ​​CI (basado en pruebas sintéticas).

    Nota : si utiliza Page Speed ​​Insights o la API de Page Speed ​​Insights (¡no, no está obsoleta!), puede obtener datos de rendimiento de CrUX para páginas específicas en lugar de solo los agregados. Estos datos pueden ser mucho más útiles para establecer objetivos de rendimiento para activos como "página de destino" o "lista de productos". Y si está utilizando CI para probar los presupuestos, debe asegurarse de que su entorno probado coincida con CrUX si usó CrUX para establecer el objetivo (¡ gracias Patrick Meenan! ).

    Si necesita ayuda para mostrar el razonamiento detrás de la priorización de la velocidad, o le gustaría visualizar una disminución en la tasa de conversión o un aumento en la tasa de rebote con un rendimiento más lento, o tal vez necesite abogar por una solución RUM en su organización, Sergey Chernyshev ha creado una Calculadora de velocidad UX , una herramienta de código abierto que le ayuda a simular datos y visualizarlos para transmitir su punto de vista.

    CrUX genera una descripción general de las distribuciones del rendimiento a lo largo del tiempo, con el tráfico recopilado de los usuarios de Google Chrome. Puedes crear el tuyo propio en Chrome UX Dashboard . ( Vista previa grande )
    Justo cuando necesita defender el rendimiento para transmitir su punto de vista: UX Speed ​​Calculator visualiza el impacto del rendimiento en las tasas de rebote, la conversión y los ingresos totales, basándose en datos reales. ( Vista previa grande )

    A veces es posible que quieras profundizar un poco más, combinando los datos provenientes de CrUX con cualquier otro dato que ya tengas para determinar rápidamente dónde se encuentran las desaceleraciones, los puntos ciegos y las ineficiencias: para tus competidores o para tu proyecto. En su trabajo, Harry Roberts ha estado utilizando una hoja de cálculo de topografía de velocidad del sitio que utiliza para desglosar el rendimiento por tipos de páginas clave y realizar un seguimiento de las diferentes métricas clave entre ellas. Puede descargar la hoja de cálculo como Google Sheets, Excel, documento de OpenOffice o CSV.

     

    Topografía de velocidad del sitio , con métricas clave representadas para páginas clave del sitio. ( Vista previa grande )

    Y si desea llegar hasta el final, puede ejecutar una auditoría de rendimiento de Lighthouse en cada página de un sitio (a través de Lightouse Parade ), con un resultado guardado como CSV. Eso le ayudará a identificar qué páginas específicas (o tipos de páginas) de sus competidores funcionan peor o mejor, y en qué podría querer centrar sus esfuerzos. (¡Sin embargo, para su propio sitio, probablemente sea mejor enviar datos a un punto final de análisis !).

    Con Lighthouse Parade , puede ejecutar una auditoría de rendimiento de Lighthouse en cada página de un sitio, con un resultado guardado como CSV. ( Vista previa grande )

    Recopile datos, configure una hoja de cálculo , reduzca un 20 % y establezca sus objetivos ( presupuestos de rendimiento ) de esta manera. Ahora tienes algo mensurable con lo que probar. Si tiene en cuenta el presupuesto y trata de enviar solo la carga útil mínima para obtener un tiempo de interacción rápido, entonces está en un camino razonable.

    ¿Necesita recursos para comenzar?

    • Addy Osmani ha escrito un artículo muy detallado sobre cómo comenzar a presupuestar el rendimiento , cómo cuantificar el impacto de las nuevas funciones y por dónde empezar cuando se excede el presupuesto.
    • La guía de Lara Hogan sobre cómo abordar diseños con un presupuesto de rendimiento puede proporcionar sugerencias útiles a los diseñadores.
    • Harry Roberts ha publicado una guía sobre cómo configurar una hoja de Google para mostrar el impacto de los scripts de terceros en el rendimiento, utilizando Request Map .
    • La Calculadora de presupuesto de rendimiento de Jonathan Fielding , la Calculadora de presupuesto de rendimiento de Katie Hempenius y las Calorías del navegador pueden ayudar a crear presupuestos (gracias a Karolina Szczur por el aviso).
    • En muchas empresas, los presupuestos de desempeño no deberían ser aspiracionales, sino más bien pragmáticos, y servir como señal de espera para evitar pasar de cierto punto. En ese caso, podría elegir el peor dato de las últimas dos semanas como umbral y partir de ahí. Presupuestos de rendimiento, le muestra de manera pragmática una estrategia para lograrlo.
    • Además, haga visibles tanto el presupuesto de rendimiento como el rendimiento actual configurando paneles con gráficos que informen sobre los tamaños de compilación. Hay muchas herramientas que le permiten lograrlo: el panel de SiteSpeed.io (código abierto), SpeedCurve y Calibre son solo algunas de ellas, y puede encontrar más herramientas en perf.rocks .

    Browser Calories le ayuda a establecer un presupuesto de rendimiento y medir si una página supera estos números o no. ( Vista previa grande )
    Trucos y guías de videojuegos

    Una vez que tenga un presupuesto, incorpórelos a su proceso de compilación con Webpack Performance Hints y Bundlesize , Lighthouse CI , PWMetrics o Sitespeed CI para hacer cumplir los presupuestos en las solicitudes de extracción y proporcionar un historial de puntuación en los comentarios de relaciones públicas.

    Para exponer los presupuestos de rendimiento a todo el equipo, integre los presupuestos de rendimiento en Lighthouse a través de Lightwallet o utilice LHCI Action para una integración rápida de Github Actions . Y si necesita algo personalizado, puede usar webpagetest-charts-api , una API de puntos finales para crear gráficos a partir de los resultados de WebPagetest.

     

    Sin embargo, la conciencia sobre el desempeño no debería provenir únicamente de los presupuestos de desempeño. Al igual que Pinterest , podrías crear una regla eslint personalizada que no permita la importación desde archivos y directorios que se sabe que tienen mucha dependencia y que inflarían el paquete. Configure una lista de paquetes "seguros" que se puedan compartir con todo el equipo.

    Además, piense en las tareas críticas del cliente que sean más beneficiosas para su negocio. Estudiar, discutir y definir umbrales de tiempo aceptables para acciones críticas y establecer marcas de tiempo de usuario "UX ready" que toda la organización haya aprobado. En muchos casos, los recorridos de los usuarios afectarán el trabajo de muchos departamentos diferentes, por lo que la alineación en términos de tiempos aceptables ayudará a respaldar o evitar discusiones sobre desempeño en el futuro. Asegúrese de que los costos adicionales de los recursos y funciones agregados sean visibles y comprendidos.

    Alinear los esfuerzos de rendimiento con otras iniciativas tecnológicas, que van desde nuevas características del producto que se está creando hasta la refactorización y el acceso a nuevas audiencias globales. Entonces, cada vez que surge una conversación sobre un mayor desarrollo, el desempeño también es parte de esa conversación. Es mucho más fácil alcanzar los objetivos de rendimiento cuando el código base está actualizado o recién se está refactorizando.

    Además, como sugirió Patrick Meenan , vale la pena planificar una secuencia de carga y compensaciones durante el proceso de diseño. Si prioriza desde el principio qué partes son más críticas y define el orden en el que deben aparecer, también sabrá qué se puede retrasar. Idealmente, ese orden también reflejará la secuencia de sus importaciones de CSS y JavaScript, por lo que será más fácil manejarlas durante el proceso de compilación. Además, considere cuál debería ser la experiencia visual en estados "intermedios", mientras se carga la página (por ejemplo, cuando las fuentes web aún no están cargadas).

    Una vez que haya establecido una sólida cultura de desempeño en su organización, intente ser un 20% más rápido que antes para mantener intactas las prioridades a medida que pasa el tiempo (¡ gracias, Guy Podjarny! ). Pero tenga en cuenta los diferentes tipos y comportamientos de uso de sus clientes (que Tobias Baldauf llamó cadencia y cohortes ), junto con el tráfico de bots y los efectos estacionales.

    Planificación, planificación, planificación. Puede resultar tentador realizar algunas optimizaciones rápidas y sencillas desde el principio (y podría ser una buena estrategia para obtener resultados rápidos), pero será muy difícil mantener el rendimiento como prioridad sin planificar y establecer objetivos realistas y realistas para la empresa. -objetivos de rendimiento personalizados.

Treo proporciona análisis competitivo basado en datos del mundo real. ( Vista previa grande )
Nuevas métricas llegaron a Lighthouse v6 a principios de 2020. ( Vista previa grande )

 

  1. Elija las métricas correctas.
    No todas las métricas son igualmente importantes . Estudie qué métricas son más importantes para su aplicación: generalmente, se definirán por qué tan rápido puede comenzar a renderizar los píxeles más importantes de su interfaz y qué tan rápido puede proporcionar capacidad de respuesta de entrada para estos píxeles renderizados. Este conocimiento le brindará el mejor objetivo de optimización para los esfuerzos continuos. Al final, no son los eventos de carga o los tiempos de respuesta del servidor los que definen la experiencia, sino la percepción de cuán ágil se siente la interfaz .

    ¿Qué significa? En lugar de centrarse en el tiempo de carga de la página completa (a través de los tiempos onLoad y DOMContentLoaded , por ejemplo), priorice la carga de la página tal como la perciben sus clientes . Eso significa centrarse en un conjunto de métricas ligeramente diferente. De hecho, elegir la métrica correcta es un proceso sin ganadores obvios.

    Según la investigación de Tim Kadlec y las notas de Marcos Iglesias en su charla , las métricas tradicionales podrían agruparse en unos pocos conjuntos. Por lo general, los necesitaremos todos para obtener una imagen completa del rendimiento y, en su caso particular, algunos de ellos serán más importantes que otros.

    • Las métricas basadas en cantidad miden la cantidad de solicitudes, el peso y la puntuación de rendimiento. Bueno para generar alarmas y monitorear cambios a lo largo del tiempo, no tan bueno para comprender la experiencia del usuario.
    • Las métricas de hitos utilizan estados durante la vida útil del proceso de carga, por ejemplo, tiempo hasta el primer byte y tiempo hasta la interacción . Bueno para describir la experiencia del usuario y el seguimiento, no tan bueno para saber qué sucede entre los hitos.
    • Las métricas de renderizado proporcionan una estimación de qué tan rápido se renderiza el contenido (por ejemplo, tiempo de inicio de renderizado , índice de velocidad ). Bueno para medir y ajustar el rendimiento de renderizado, pero no tan bueno para medir cuándo aparece contenido importante y se puede interactuar con él.
    • Las métricas personalizadas miden un evento particular y personalizado para el usuario, por ejemplo, el tiempo hasta el primer tweet de Twitter y PinnerWaitTime de Pinterest . Bueno para describir la experiencia del usuario con precisión, no tan bueno para escalar las métricas y compararlas con la competencia.

    Para completar el panorama, normalmente buscamos métricas útiles entre todos estos grupos. Generalmente, los más específicos y relevantes son:

    • Tiempo de interacción (TTI)
      El punto en el que el diseño se ha estabilizado , las fuentes web clave son visibles y el hilo principal está lo suficientemente disponible para manejar la entrada del usuario; básicamente, la marca de tiempo en la que un usuario puede interactuar con la interfaz de usuario. Las métricas clave para comprender cuánta espera tiene que experimentar un usuario para utilizar el sitio sin demoras. Boris Schapira ha escrito una publicación detallada sobre cómo medir el TTI de manera confiable .
    • Retraso de la primera entrada (FID) , o capacidad de respuesta de entrada
      El tiempo desde que un usuario interactúa por primera vez con su sitio hasta el momento en que el navegador realmente puede responder a esa interacción. Complementa muy bien a TTI ya que describe la parte que falta en la imagen: qué sucede cuando un usuario realmente interactúa con el sitio. Diseñado únicamente como métrica de RON. Hay una biblioteca de JavaScript para medir FID en el navegador.
    • Pintura con contenido más grande (LCP)
      Marca el punto en la línea de tiempo de carga de la página en el que es probable que se haya cargado el contenido importante de la página . Se supone que el elemento más importante de la página es el más grande visible en la ventana gráfica del usuario . Si los elementos se representan tanto por encima como por debajo del pliegue, sólo la parte visible se considera relevante.
    • Tiempo total de bloqueo ( TBT )
      Una métrica que ayuda a cuantificar la gravedad de qué tan no interactiva es una página antes de que se vuelva confiablemente interactiva (es decir, el hilo principal ha estado libre de tareas que se ejecuten durante más de 50 ms ( tareas largas ) durante al menos 5p). La métrica mide la cantidad total de tiempo entre la primera pintura y el tiempo de interacción (TTI), donde el hilo principal estuvo bloqueado durante el tiempo suficiente para evitar la capacidad de respuesta de la entrada. No es de extrañar, entonces, que un TBT bajo sea un buen indicador de un buen desempeño. (gracias, Artem, Phil)
    • Cambio de diseño acumulativo ( CLS )
      La métrica destaca la frecuencia con la que los usuarios experimentan cambios de diseño inesperados ( reflujos ) al acceder al sitio. Examina elementos inestables y su impacto en la experiencia general. Cuanto menor sea la puntuación, mejor.
    • Índice de velocidad
      Mide la rapidez con la que se completa visualmente el contenido de la página; cuanto menor sea la puntuación, mejor. La puntuación del índice de velocidad se calcula en función de la velocidad del progreso visual , pero es simplemente un valor calculado. También es sensible al tamaño de la ventana gráfica, por lo que debe definir una variedad de configuraciones de prueba que coincidan con su público objetivo. Tenga en cuenta que se está volviendo menos importante y que LCP se está convirtiendo en una métrica más relevante (¡ gracias, Boris , Artem! ).
    • Tiempo de CPU invertido
      Una métrica que muestra con qué frecuencia y durante cuánto tiempo se bloquea el hilo principal, trabajando en pintura, renderizado, secuencias de comandos y carga. El tiempo elevado de CPU es un claro indicador de una experiencia desagradable , es decir, cuando el usuario experimenta un retraso notable entre su acción y una respuesta. Con WebPageTest, puede seleccionar "Capturar línea de tiempo de herramientas de desarrollo" en la pestaña "Chrome" para exponer el desglose del hilo principal mientras se ejecuta en cualquier dispositivo que utilice WebPageTest.
    • Costos de CPU a nivel de componente
      Al igual que con el tiempo de CPU invertido , esta métrica, propuesta por Stoyan Stefanov, explora el impacto de JavaScript en la CPU . La idea es utilizar el recuento de instrucciones de la CPU por componente para comprender su impacto en la experiencia general, de forma aislada. Podría implementarse usando Puppeteer y Chrome .
    • FrustrationIndex
      Si bien muchas de las métricas presentadas anteriormente explican cuándo ocurre un evento en particular, FrustrationIndex de Tim Vereecke analiza las brechas entre las métricas en lugar de analizarlas individualmente. Analiza los hitos clave percibidos por el usuario final, como el título es visible, el primer contenido es visible, visualmente listo y la página parece lista y calcula una puntuación que indica el nivel de frustración al cargar una página. Cuanto mayor sea la brecha, mayores serán las posibilidades de que un usuario se sienta frustrado. Potencialmente un buen KPI para la experiencia del usuario. Tim ha publicado una publicación detallada sobre FrustrationIndex y cómo funciona.
    • Impacto del peso del anuncio
      Si su sitio depende de los ingresos generados por la publicidad, resulta útil realizar un seguimiento del peso del código relacionado con el anuncio. El script de Paddy Ganti construye dos URL (una normal y otra que bloquea los anuncios), solicita la generación de una comparación de vídeos a través de WebPageTest e informa un delta.
    • Métricas de desviación
      Como señalaron los ingenieros de Wikipedia , los datos sobre cuánta variación existe en sus resultados podrían informarle qué tan confiables son sus instrumentos y cuánta atención debe prestar a las desviaciones y los valores atípicos. Una gran variación es un indicador de los ajustes necesarios en la configuración. También ayuda a comprender si ciertas páginas son más difíciles de medir de manera confiable, por ejemplo, debido a scripts de terceros que causan variaciones significativas. También podría ser una buena idea realizar un seguimiento de la versión del navegador para comprender los cambios en el rendimiento cuando se lanza una nueva versión del navegador.
    • Métricas personalizadas
      Las métricas personalizadas se definen según las necesidades de su negocio y la experiencia del cliente. Requiere que identifique píxeles importantes , scripts críticos , CSS necesarios y activos relevantes y mida la rapidez con la que se entregan al usuario. Para eso, puede monitorear los tiempos de renderizado de Hero o usar la API de rendimiento , marcando marcas de tiempo particulares para eventos que son importantes para su negocio. Además, puede recopilar métricas personalizadas con WebPagetest ejecutando JavaScript arbitrario al final de una prueba.

    Tenga en cuenta que la primera pintura significativa (FMP) no aparece en la descripción general anterior. Solía ​​proporcionar una idea de la rapidez con la que el servidor genera datos . Un FMP largo generalmente indicaba que JavaScript bloqueaba el hilo principal, pero también podría estar relacionado con problemas de back-end/servidor. Sin embargo, la métrica ha quedado obsoleta recientemente porque parece no ser precisa en aproximadamente el 20% de los casos. Fue reemplazado efectivamente por LCP, que es más confiable y más fácil de razonar. Ya no es compatible con Lighthouse . Verifique las últimas recomendaciones y métricas de rendimiento centradas en el usuario solo para asegurarse de que está en la página segura ( gracias, Patrick Meenan ).

     

     

    Steve Souders tiene una explicación detallada de muchas de estas métricas . Es importante tener en cuenta que, si bien el tiempo de interacción se mide mediante la ejecución de auditorías automatizadas en el llamado entorno de laboratorio , el retardo de la primera entrada representa la experiencia real del usuario, y los usuarios reales experimentan un retraso notable. En general, probablemente sea una buena idea medirlos y realizar un seguimiento siempre de ambos.

    Dependiendo del contexto de su aplicación, las métricas preferidas pueden diferir: por ejemplo, para la interfaz de usuario de Netflix TV, la capacidad de respuesta de las entradas clave, el uso de memoria y el TTI son más importantes, y para Wikipedia, los primeros/últimos cambios visuales y las métricas de tiempo de CPU invertido son más importantes.

    Nota : tanto FID como TTI no tienen en cuenta el comportamiento de desplazamiento; El desplaz






    Tal vez te puede interesar:

    1. ¿Deberían abrirse los enlaces en ventanas nuevas?
    2. 24 excelentes tutoriales de AJAX
    3. 70 técnicas nuevas y útiles de AJAX y JavaScript
    4. Más de 45 excelentes recursos y repositorios de fragmentos de código

Lista de verificación de rendimiento de front-end 2021 (PDF, Apple Pages, MS Word)

Lista de verificación de rendimiento de front-end 2021 (PDF, Apple Pages, MS Word)

Índice Tabla de contenido Preparándose: plani

programar

es

https://aprendeprogramando.es/static/images/programar-lista-de-verificacion-de-rendimiento-de-front-end-2021-pdf-962-0.jpg

2024-05-20

 

Lista de verificación de rendimiento de front-end 2021 (PDF, Apple Pages, MS Word)
Lista de verificación de rendimiento de front-end 2021 (PDF, Apple Pages, MS Word)

Si crees que alguno de los contenidos (texto, imagenes o multimedia) en esta página infringe tus derechos relativos a propiedad intelectual, marcas registradas o cualquier otro de tus derechos, por favor ponte en contacto con nosotros en el mail [email protected] y retiraremos este contenido inmediatamente

 

 

Top 20