Cómo Medir el Rendimiento de manera Efectiva?

Rate this content
Bookmark

La mayoría de las personas en nuestra industria saben qué es Lighthouse o Page Speed Insights y los utilizan regularmente. Desafortunadamente, la mayoría de ellos no tienen idea de cómo funcionan, lo que lleva a terribles conceptos erróneos y malentendidos, especialmente para los propietarios de negocios no técnicos. En esta charla, quiero ayudar a todos a aprovechar mejor estas herramientas explicando cómo funcionan, cuál es su objetivo y cómo interpretar los datos para llegar a las conclusiones correctas.

28 min
20 Oct, 2021

Video Summary and Transcription

Esta Charla discute la evolución de las herramientas de medición de rendimiento y la importancia del rendimiento en el desarrollo web. Presenta Google Lighthouse como una herramienta que proporciona información detallada sobre el rendimiento de las páginas web. La Charla enfatiza la importancia de los Core Web Vitals, incluyendo Largest Contentful Paint, First Input Delay y Cumulative Layout Shift. Sugiere alojar el entorno de Lighthouse localmente y utilizar Lighthouse CI para la medición continua del rendimiento. La Charla también destaca el impacto de los Core Web Vitals en el SEO y la importancia de priorizar los datos de campo sobre los datos de laboratorio.

Available in English

1. Introducción a las herramientas de medición de rendimiento

Short description:

Hola a todos. Mi nombre es Filip Rakowski, el CEO y cofundador de Viewstorefront. Hoy hablaré sobre las herramientas de medición de rendimiento y cómo han evolucionado a lo largo de los años. En el pasado, optimizar el rendimiento era un desafío y solo un pequeño grupo de desarrolladores sabía cómo medirlo y optimizarlo. Sin embargo, con la introducción de Google Lighthouse en 2018, la medición de rendimiento se volvió más accesible. El auge de las aplicaciones web progresivas (PWAs) también enfatizó la importancia de la velocidad en la navegación móvil. Ahora, el rendimiento es ampliamente reconocido como un aspecto crucial del desarrollo web.

Mi nombre es Filip Rakowski. Soy el CEO y cofundador de Viewstorefront. Si no sabes qué es Viewstorefront, permíteme explicarlo rápidamente. Viewstorefront es una herramienta de código abierto que permite construir tiendas increíbles con prácticamente cualquier pila de comercio electrónico. Así que no importa qué problemas puedas encontrar al construir tiendas de comercio electrónico, probablemente tengamos una herramienta para eso. Así que orquestación, almacenamiento en caché, sistemas de diseño, lo tenemos todo.

Y puedes obtener más información sobre el proyecto o darnos una estrella, porque somos de código abierto, revisando nuestro repositorio en GitHub. Es posible que también me conozcas por una serie muy conocida en ViewSchool, sobre la optimización de Vue.js performance. Y hoy hablaré sobre el tema, y para ser más preciso y preciso, hablaré sobre las herramientas de medición de performance. Así que hay muchas ideas equivocadas sobre el tema, porque la forma en que se mide el performance en estos días definitivamente no es fácil de entender. Sin embargo, las personas utilizan estas herramientas y, sin saber exactamente cómo funcionan, es muy fácil sacar información falsa de los resultados. Así que exploremos este tema en profundidad.

Créanme o no, hace apenas cuatro o cinco años, optimizar el performance de las aplicaciones web era algo muy exótico. Solo un pequeño grupo de desarrolladores realmente sabía cómo medirlo y solo los elegidos sabían cómo optimizarlo. Aunque ya teníamos algunas herramientas excelentes para medir el performance, la mayoría de nosotros no teníamos idea de su existencia. Y optimizar el performance generalmente significaba seguir un montón de mejores prácticas para la mayoría de nosotros, tal vez medir el evento de carga, pero eso era generalmente todo. Y solo los grandes jugadores y los gobiernos realmente se preocupaban por eso. Y creo que la razón de eso era simple, creo que era demasiado difícil para la mayoría de los desarrolladores medir eficazmente el performance. Y también, no había herramientas que proporcionaran información muy fácil de entender.

También el conocimiento sobre el impacto empresarial de un buen o mal performance, no era tan común en la industria, y no era tan común para los propietarios de negocios. Todo cambió en 2018 cuando Google introdujo Google Lighthouse. Fue la primera herramienta de medición de performance que básicamente tenía como objetivo simplificar algo que recientemente era complejo y muy, muy difícil de entender. Al mismo tiempo, se hizo evidente para todos que, ya sabes, la forma preferida de consumir la web para la mayoría de los usuarios es básicamente a través de dispositivos móviles como tabletas o teléfonos inteligentes, principalmente este último. Y esto aceleró la popularidad de un término, aplicación web progresiva, que se introdujo por primera vez, creo que en 2015. Y el objetivo de las PWAs era básicamente brindar una mejor experiencia de navegación móvil a todos los usuarios, independientemente de su conectividad de red o capacidades del dispositivo. Y una de las características clave promovidas por las PWAs era la velocidad. Por supuesto, todo esto fue seguido por una evangelización muy agresiva por parte de Google en eventos de todo el mundo, YouTube, etc. Pero esto es algo bueno porque el performance es súper importante. Y antes estábamos ciegos, ahora vemos todo.

2. Google Lighthouse y las puntuaciones métricas

Short description:

Sumergámonos en Google Lighthouse, una herramienta de medición de rendimiento que proporciona información detallada sobre el rendimiento de una página web. Asigna una puntuación entre 1 y 100, donde las puntuaciones por debajo de 50 se consideran malas y las puntuaciones por encima de 90 se consideran buenas. Cada métrica tiene un peso que refleja su impacto en la experiencia general del usuario. Google utiliza datos del mundo real de HTTP Archive para determinar el rango de puntuaciones buenas, medias o malas.

Comencemos la charla de hoy con una inmersión profunda en Google Lighthouse. Estoy bastante seguro de que la mayoría de ustedes ha utilizado esta herramienta al menos una vez en su carrera profesional. Y no es sorprendente. Esta auditoría está disponible a través de extensiones del navegador y páginas externas. También se puede realizar directamente desde las Chrome DevTools. Simplemente haz clic en la pestaña de Auditoría, ejecuta la prueba en cualquier sitio web y voilà, te proporcionará información detallada sobre el rendimiento de tu página en relación con ciertas métricas, con el objetivo de describir la experiencia real de tus usuarios de la manera más precisa posible.

Entonces, Livehouse básicamente reduce el rendimiento de un sitio web a un número único, entre uno y cien. También se puede tratar como un porcentaje, donde una puntuación por debajo de 50 se considera mala y una puntuación por encima de 90 se considera buena. Volveré a este tema, porque podría resultar sorprendente que solo el 10% se considere bueno. Pero, volviendo al tema. ¿De dónde provienen estos números mágicos? Resulta que cada métrica tiene su propio peso que corresponde a su impacto en la experiencia general del usuario final. Como puedes ver aquí, si mejoramos el tiempo total de bloqueo, la pintura del contenido más grande o el desplazamiento de diseño acumulativo, mejoraremos nuestra puntuación en Livehouse mucho más rápido que optimizando otras métricas. Por supuesto, es importante centrarse en todas ellas, ya que cada una describe una pieza diferente que contribuye a la experiencia general de tus usuarios, pero hay algunas métricas que Google ha identificado como más importantes que otras, en el sentido de que su impacto en la experiencia del usuario, la experiencia percibida por el usuario, es mayor. Por supuesto, todo es subjetivo, pero esto es lo que dicen los datos, así que tenemos que creerlo.

De acuerdo, ahora sabemos cómo se calcula la puntuación de Google Livehouse en general, pero lo que no sabemos es básicamente cómo se calcula la puntuación de las métricas individuales. ¿Qué quiero decir con esto? Digamos que tenemos el tiempo total de bloqueo. ¿Cómo sabemos si un segundo es un resultado bueno o malo? ¿De dónde lo sabemos? Y Google utiliza datos del mundo real recopilados por HTTP Archive. Y si no sabes qué es HTTP Archive, te animo realmente a que lo revises, porque es simplemente impresionante. Contiene mucha información útil sobre la web en general y cómo se utiliza tanto por usuarios reales como por problemas. Y puede ayudarte a comprender qué es importante y cómo se desempeña tu sitio web en comparación con otros en tu campo o en diferentes campos. Y te advierto, parte de la información que encontrarás allí puede ser realmente, realmente deprimente o al menos sorprendente. Por ejemplo, mi ejemplo favorito, en realidad, puedes descubrir que en 2021, la cantidad promedio de datos comprimidos, repito, datos comprimidos de JavaScript enviados por un sitio web estadístico, es casi de 450 kilobytes en dispositivos móviles. 450 kilobytes de datos comprimidos en un dispositivo móvil. Eso son varios megabytes de JavaScript sin comprimir. Para dispositivos de gama media o baja, si obtienes una experiencia realmente, realmente mala y un tiempo de carga, ¡puf!, podrías hacer un café, volver y aún esperar hasta que tu sitio web esté listo. De verdad, hay muchos ejemplos donde puedes ver que alguna página se carga en 13, 14 o incluso 15 segundos en un dispositivo móvil. ¿Esperarías tanto tiempo? No creo. Bueno, volviendo al tema principal. Basándose en los datos de cada métrica de HTTP Archive, Google establece el rango para una puntuación buena, media o mala.

3. Lighthouse Score and Metric Changes

Short description:

Recuerda la puntuación de Lighthouse. Obtener una puntuación en el 90% inferior del rango se considera una puntuación mala o media, porque el 90% del sitio web es malo o medio. Tanto las métricas como sus pesos en Lighthouse cambian con el tiempo a medida que Google aprende cosas nuevas. La puntuación es más precisa con cada versión, midiendo el impacto del mundo real de diferentes métricas en la experiencia del usuario. Comparar las puntuaciones generales a lo largo del tiempo es engañoso, ya que el algoritmo puede cambiar. En cambio, concéntrate en comparar las métricas individuales y considera las Core Web Vitals como medidas vitales para el rendimiento del sitio web.

Entonces, para cada métrica, también el 10% superior se percibe como buenos resultados y el 50% inferior se percibe como malos, todo lo que está entre un resultado medio. Y podrías decir que clasificar solo el 10% superior de todos los sitios web como bueno no es suficiente. Pero si piensas un poco. Y especialmente piensas un poco en la diapositiva anterior, te darás cuenta rápidamente de que básicamente la mayoría de los sitios web son extremadamente lentos. Por lo tanto, obtener una puntuación en el 90% inferior del rango se considera una puntuación mala o media, porque el 90% del sitio web es malo o medio.

Y tu puntuación en Lighthouse para cada métrica individual se determina por tu posición en el gráfico. Si estás en la parte superior, obtienes el 100%, si estás en la parte inferior, obtienes el 0. Simple.

Hay una cosa importante que todos los que usan Lighthouse deben tener en cuenta. Tanto las métricas como sus pesos cambian con el tiempo. No son persistentes. ¿Por qué? Bueno, obviamente, con el tiempo Google aprende cosas nuevas. Aprenden cosas nuevas sobre el impacto de ciertas métricas y comportamientos en la experiencia del usuario y actualizan periódicamente el algoritmo de puntuación de Lighthouse para que sea más preciso. Y con cada versión, la puntuación es más precisa, mide y describe el impacto del mundo real de diferentes métricas en la experiencia del usuario. Y realmente no es fácil encontrar buenas métricas y pesos porque podemos medir el rendimiento desde muchas perspectivas diferentes y descubrir cómo cada una de ellas influye en la experiencia general es muy difícil. Por eso tenemos Lighthouse 7 y probablemente también tendremos Lighthouse 17. Aquí tienes un ejemplo de los cambios entre Lighthouse 5 y Lighthouse 6. Como puedes ver, no solo cambian los pesos de la caché, sino que también se reemplazan dos métricas de Lighthouse 5 en Lighthouse 6. Desde Lighthouse 7, parece que ya hemos establecido un buen conjunto de métricas para medir el rendimiento general, pero los pesos aún se están ajustando. Es importante tener en cuenta que la puntuación está cambiando porque, por ejemplo, si evalúas tu sitio web hoy y guardas tu puntuación de rendimiento, digamos que fue 60, y luego lo evalúas dentro de un año y será 70. ¿Significa que fue mejor? ¿Significa que fue peor? No significa nada porque el algoritmo podría haber cambiado durante ese tiempo. Podría haber mejorado o empeorado porque el algoritmo ha cambiado, no porque hayas mejorado algo o hayas fallado en algo más. Por eso este tipo de comparación solo tiene sentido cuando se comparan las métricas individuales. Realmente te animo a hacer eso, a guardar eso. También te contaré un poco sobre la herramienta que automatiza eso. Nunca, nunca compares la puntuación real porque es muy engañosa y con el tiempo también nos daremos cuenta de que de todas estas métricas que conocemos, hay tres que son una especie de conjunto mínimo de medidas que son vitales para el rendimiento del sitio web. Y las llaman Core Web Vitals, que es un nombre bastante preciso. Y Google las describe como señales de calidad, y creo que esa es la descripción perfecta en realidad, porque no hay métricas que te digan si el sitio web ofrece una experiencia buena o mala. Esto no es algo que puedas, ya sabes, simplemente medir. Y nunca debemos seguirlos ciegamente, esto es solo una señal.

4. Introducción a las Core Web Vitals

Short description:

Cada métrica y herramienta de prueba proporciona una señal sobre la calidad de un sitio web. La primera Core Web Vital es Largest Contentful Paint (LCP), que mide cuánto tiempo tarda en aparecer el contenido más grande en la pantalla. LCP es crucial para el rendimiento de carga, y un buen LCP está por debajo de dos segundos y medio.

Y cada métrica y herramienta de prueba siempre te proporciona solo una señal sobre la calidad de un sitio web, nada más. Volviendo a esto, tenemos tres Core Web Vitals. El primero se llama Largest Contentful Paint, que básicamente mide cuánto tiempo tarda el sitio web en mostrar el contenido más grande en la pantalla por encima del valor predeterminado. Puede ser una imagen, un enlace o un campo de texto, realmente no importa. Esta métrica describe el rendimiento de carga porque te dice cuánto tiempo necesita esperar hasta que aparezca la parte más grande de la interfaz de usuario. Si esta definición no te dice nada, veámoslo en el ejemplo. En la primera imagen vemos que LCP es la imagen en el medio, y aparece en el quinto fotograma. Suponiendo que cada fotograma es de un segundo, nuestro LCP es de cinco segundos. ¿Entendido? En la imagen de abajo, vemos que esto es básicamente esta imagen de Instagram, y nuestro LCP es después de tres segundos. Un buen LCP está por debajo de dos segundos y medio, y malo está por encima de cuatro segundos. Por lo tanto, podemos concluir rápidamente que no hubo un buen LCP en los ejemplos anteriores.

5. Métricas de rendimiento y Core Web Vitals

Short description:

First Input Delay mide el tiempo que los usuarios necesitan esperar para recibir la primera respuesta de su acción. Un buen valor está por debajo de 100 milisegundos, ya que después de 100 milisegundos, los usuarios pueden percibir una demora. Cumulative Layout Shift mide la estabilidad visual, y un buen puntaje es menos del 10% de cambios en el diseño. Core Web Vitals son un conjunto mínimo de señales de calidad para el rendimiento percibido. La puntuación de Lighthouse tiene limitaciones, como no distinguir entre aplicaciones de una sola página y de varias páginas, y no proporcionar información sobre cargas pesadas o rendimiento de almacenamiento en caché del cliente.

Otra métrica que mide la capacidad de respuesta del sitio web, además de la carga y la falta de capacidad de respuesta, es el First Input Delay. En pocas palabras, es el tiempo que el usuario necesita esperar hasta que vea la primera respuesta de su acción. Estoy seguro de que lo has visto muchas veces. Ingresas al sitio web, haces clic en el enlace que aparece en la ventana visible, pero el sitio web aún se está cargando, por lo que tienes que esperar un poco hasta que la navegación a otra página realmente ocurra, o se abra una ventana de modelo, o suceda alguna otra cosa . Esto es exactamente el First Input Delay.

Esto ocurre solo si tienes tareas largas que ocupan el hilo principal durante más de 100 milisegundos. Si no sabes qué es el hilo principal, comienza leyendo sobre cómo funcionan los bucles de eventos. Es realmente útil. Bueno, volviendo. Entonces, si el usuario hace clic en algo, debe esperar a que esa tarea termine y luego la acción ocurre. Un buen valor de First Input Delay está por debajo de 100 milisegundos. Esto se debe a que, según los estudios realizados, 100 milisegundos es en realidad un umbral para una respuesta instantánea percibida. Por lo tanto, después de 100 milisegundos, el usuario notará que la acción se retrasó y todo por debajo de 100 milisegundos se considera instantáneo. Es información muy útil.

Y por último, pero no menos importante, el cumulative layout shift mide la estabilidad visual. Básicamente te dice si hay cambios en el diseño durante el proceso. Por ejemplo, si la imagen se ha movido o el texto se ha movido. Y el CLS generalmente ocurre cuando no tienes marcadores de posición para la parte de la interfaz de usuario que se carga dinámicamente, como imágenes en la pila de imágenes, por ejemplo. Y aquí vemos un ejemplo del cambio de diseño. Entonces, el botón Haz clic en mí ha aparecido y debido a eso tuvimos que desplazar toda la caja verde. El buen puntaje para CLS es cuando menos del 10% de tu diseño cambia durante el proceso de carga y el malo es cuando más del 25% cambia. E intuitivamente, creo que es correcto. Por lo tanto, los Core Web Vitals son un conjunto mínimo de señales de calidad para un buen rendimiento percibido, midiendo la cargaperformance, la interactividad de la página y la estabilidad visual.

Y creo que ya es un gran paso adelante desde Lighthouse 1, donde en realidad cada página tenía una puntuación de 100 y había muchas métricas extrañas, y teníamos una comprensión muy ingenua de lo que más importa en una buena user experience. Pero, sabes, todavía hay margen de mejora, y también quiero que estés consciente de eso. Por ejemplo, la auditoría de Lighthouse no mostrará ninguna diferencia entre una aplicación de una sola página y una aplicación de varias páginas, aunque la primera tiene una navegación en la aplicación mucho más rápida. Entonces, aunque ambas tendrán la misma puntuación, la experiencia percibida de tus usuarios siempre será mejor en la aplicación de una sola página, porque la navegación en la aplicación es mucho más rápida. Además, la puntuación de Lighthouse no te dirá nada sobre qué tan bien o qué tan mal funciona tu sitio web bajo cargas pesadas, o qué tan bien se está almacenando en caché del cliente, es decir, qué tan bien se están gestionando las visitas posteriores. Solo te dirá si se almacenó en caché o no. Pero, sabes, eso es todo lo que tenemos en este momento, y creo que definitivamente es mejor que nada, y es bastante preciso, no me malinterpretes.

6. Ejecutando la Auditoría de Lighthouse Localmente

Short description:

Si deseas medir continuamente el rendimiento para cada lanzamiento o con cada solicitud de extracción, te sugiero encarecidamente que alojes el entorno de Lighthouse localmente y utilices herramientas como Lighthouse CI, que está disponible como una acción de GitHub.

Solo hay un problema. Si ejecutas una auditoría de Lighthouse localmente en diferentes dispositivos, casi siempre obtendrás diferentes puntuaciones porque está influenciado por muchos factores, como la potencia de tu computadora, tu conectividad de red, tus extensiones de navegador. Por supuesto, puedes aplicar trucos, navegar en modo incógnito, pero no eliminará el problema por completo. Si deseas medir continuamente el rendimiento para cada lanzamiento o con cada solicitud de extracción, te sugiero encarecidamente que alojes el entorno de Lighthouse localmente y utilices herramientas como Lighthouse CI, que está disponible como una acción de GitHub. Es una gran herramienta y ejecutará automáticamente una auditoría de Lighthouse en cada solicitud de extracción con solo unas pocas líneas de código.

7. Lighthouse CI y LabData vs FieldData

Short description:

Si ejecutas Lighthouse CI, te proporcionará una vista detallada de la puntuación y cómo ha cambiado con el tiempo. LabData proporciona información de depuración, mientras que FieldData revela cuellos de botella del mundo real. El Chrome User Experience Report recopila métricas de rendimiento de los usuarios de Chrome y está disponible si tu sitio web es rastreable.

Si ejecutas Lighthouse CI, te proporcionará una vista detallada de la puntuación. Por ejemplo, cómo ha cambiado con el tiempo desde la versión anterior, cómo han cambiado las métricas. Verás de inmediato si una determinada versión de la solicitud de extracción contribuye a un mejor o peor rendimiento. Eso es lo más importante. Esta es la razón principal por la que vale la pena introducir Lighthouse CI en tus flujos de trabajo.

Vale, pero la solución no es perfecta, porque el hecho de que tu sitio web funcione muy bien en tu entorno controlado solo significa que funciona muy bien en tu entorno controlado. Porque si estás probando en iPhones o MacBooks de alta gama, generalmente puedes esperar buenos resultados. Pero no todos tus usuarios tendrán dispositivos de alta gama y buen acceso a Internet. Entonces, básicamente, hay dos tipos de datos. Uno se llama LabData, y esto es lo que te proporciona Lighthouse, y de lo que hemos estado discutiendo hasta ahora. Básicamente son los datos que siempre provienen de un entorno controlado, como tu computadora. Pero también hay otro tipo de datos llamado FieldData que, como su nombre indica, proviene del mundo real. También lo sugiere la imagen. Y es proporcionado por usuarios del mundo real. Y en realidad necesitas ambos. Entonces, LabData es principalmente útil para la depuración, y como vimos anteriormente, podemos ver allí resultados y mejoras o regresiones en ciertas métricas después de cada lanzamiento o después de cada solicitud de extracción. Y también podemos reproducir esos resultados muy fácilmente. El problema es que no nos proporciona información real sobre los cuellos de botella del mundo real de nuestro sitio web. Y aquí es donde brilla FieldData.

Para ilustrar también por qué necesitamos tanto LabData como FieldData, quiero mostrarte dos ejemplos del mundo real. Entonces, aunque la puntuación de Latke aquí arriba es terrible, alrededor del 80-90% de los usuarios experimenta un gran rendimiento. Entonces, las barras que vemos en el medio, eso es FieldData. Otro ejemplo, un caso opuesto real. Entonces, aunque tenemos una puntuación de Lighthouse bastante decente arriba, 73 para un sitio web de comercio electrónico es muy decente, la mayoría de los usuarios experimentan un mal rendimiento para un sitio web médico. Entonces, esto realmente es solo un indicador, y LabData no es suficiente información para determinar si nuestro sitio web está funcionando bien o mal. Entonces, ¿dónde podemos encontrar los FieldData entonces? Google lanzó algo llamado Chrome User Experience Report, y eso es exactamente lo que sugiere el nombre. Así que debemos admitir que son buenos para nombrar, como Hurley Pytel's, Chrome User Experience Report, todas esas cosas. Es un informe de la experiencia del usuario real entre los usuarios de Chrome, y Google recopila cuatro métricas de rendimiento cada vez que visita un sitio web y las envía a la base de datos de CrUX. Por cierto, puedes desactivarlo en Chrome si quieres, pero de forma predeterminada, está activado. Y para que estos datos estén disponibles para tu página o sitio web, debe ser rastreable, así que tenlo en cuenta.

8. PageSpeed Insights y Lab Data

Short description:

Y estos datos del Informe de Experiencia del Usuario de Chrome están disponibles en PageSpeed Insights, Google BigQuery y el Panel de Experiencia del Usuario de Chrome en Data Studio. PageSpeed Insights es una herramienta de medición de rendimiento que ejecuta la Auditoría de Rendimiento de Lighthouse en tu sitio web, pero también muestra los datos de campo recopilados del Informe de Experiencia del Usuario de Chrome. Los datos de laboratorio son solo un indicador y los datos de la Auditoría de Lighthouse de PageSpeed Insights provienen del centro de datos de Google. Los datos de laboratorio muestran qué tan bien funciona tu sitio web en relación con los vitales coloreados y la primera entrada, la primera pintura de concentración.

Y estos datos del Informe de Experiencia del Usuario de Chrome están disponibles en PageSpeed Insights, Google BigQuery, y el Panel de Experiencia del Usuario de Chrome en Data Studio. Y no hablaré sobre este último, pero simplemente te animo, te animo mucho a que lo revises, porque el Panel de Experiencia del Usuario de Chrome en Data Studio es increíble. Te permite crear informes muy detallados y puedes especificar qué métricas te gustaría ver, cómo han cambiado con el tiempo, qué dispositivos para qué tipos de usuarios. Es súper, súper útil.

Y hoy hablaremos sobre el primero, que es PageSpeed Insights. Entonces, PageSpeed Insights. PageSpeed Insights es una herramienta de medición de rendimiento que ejecuta la Auditoría de Rendimiento de Lighthouse en tu sitio web, pero también muestra los datos de campo recopilados del Informe de Experiencia del Usuario de Chrome. Entonces, PageSpeed Insights combina de alguna manera las dos formas de obtener los datos que hemos visto. Utiliza tanto Lighthouse como el Informe de Experiencia del Usuario de Chrome. Esencialmente, es una auditoría que nos brinda toda la información que necesitaríamos.

Y los datos de laboratorio son los que se utilizan para calcular la puntuación de Lighthouse. Por eso no deberías centrarte tanto en mejorar esta parte. Es solo un indicador. Pero podrías preguntar, ¿cuál es la diferencia entre los datos de laboratorio de PageSpeed Insights y los datos de laboratorio que obtengo al ejecutar la puntuación de Lighthouse en mi propio dispositivo? ¿Verdad? Los datos de la Auditoría de Lighthouse de PageSpeed Insights provienen del centro de datos de Google. Básicamente, están ejecutando la prueba, la auditoría, en uno de los centros de datos de Google en lugar de una computadora. Y el sitio web generalmente utiliza el centro de datos más cercano a tu ubicación. Pero a veces, en mi experiencia, muchas más veces de lo habitual, podrías usar otro si el más cercano está bajo una carga pesada. Y por eso, a veces puedo obtener resultados completamente diferentes en la misma página si ejecutas la prueba una tras otra. Realmente podrían ser completamente diferentes. Y esa es otra razón para no poner demasiado énfasis en los datos de laboratorio. Tratémoslo como un indicador. Además, para dar un poco más de detalle, todas las pruebas se ejecutan en este centro de datos, pero también en el emulador Motorola Moto G4, que es un dispositivo móvil típico de gama media. Entonces, siempre y cuando tus usuarios no estén utilizando esto, esta puntuación no será una simulación realista. Lo que realmente importa son los datos de campo y se recopilan de los últimos 28 días en este ejemplo en particular. Pero quiero decir, en cada auditoría de PageSpeed Insights, se recopilan de 28 días. Entonces, si hiciste una actualización, deberás esperar todo un mes para ver si hubo una mejora o no. Y los datos de laboratorio muestran qué tan bien funciona tu sitio web en relación con los vitales coloreados y la primera entrada, la primera pintura de concentración. El porcentaje de cada color muestra cuántos usuarios experimentan resultados buenos, medianos o malos. Por ejemplo, si vemos una barra verde completa. Eso significa que todos los usuarios experimentan buenos resultados.

9. Impacto de los Core Web Vitals en el SEO

Short description:

Al utilizar PageSpeed Insights, siempre prioriza los datos de campo sobre los datos de laboratorio. El rendimiento tiene un impacto en el SEO, especialmente en los resultados de búsqueda móviles. Es posible que los dispositivos de escritorio se incluyan en el futuro. Solo los datos de campo son importantes para la optimización del SEO. Google analiza cada métrica por separado y un buen percentil 75 resulta en un impulso en el SEO. En este ejemplo, se logra un impulso en el SEO para el Retraso de la Primera Entrada, LCP y CLS.

Escenario perfecto. Entonces, para resumir, al utilizar PageSpeed Insights, siempre debes mirar los data de campo cuando busques información significativa del mundo real. Y puedes utilizar los datos de laboratorio para verificar si hubo una mejora inmediatamente después de realizar los cambios. Pero la parte más importante aquí son los datos de laboratorio, punto.

Ahora algo que todos hemos estado esperando y algo con lo que mucha gente lucha. También yo, tuve muchos problemas para encontrar la información correcta porque estaba cambiando con el tiempo. Entonces, ¿cuál es el impacto de los Core Web Vitals y básicamente del rendimiento en el SEO? Es algo nuevo que se introdujo este año y la respuesta corta es sí. El rendimiento afecta al SEO, pero en este momento solo influye en los resultados de búsqueda móviles y solo tiene en cuenta los datos recopilados de dispositivos móviles. Por lo tanto, el tema móvil es algo en lo que deberías fijarte, me refiero a los datos de campo móviles. Es muy probable que también sea relevante para los dispositivos de escritorio en algún momento, pero aún no lo es. Además, solo importan los datos de campo, por lo que eso es lo que debes optimizar, los datos de laboratorio no tienen ninguna influencia en el SEO. Entonces, si quieres obtener un impulso en el SEO, verifica tus datos de campo en PageSpeed Insights y optimízalos.

Veamos un ejemplo del mundo real y cómo funciona en Dev. Google analiza cada una de las cuatro métricas recopiladas por separado y si el percentil 75 de una métrica determinada es bueno, obtendrás un impulso en el SEO de esa métrica en particular. Si no es así, no obtendrás un impulso en el SEO. Solo eso. Eso es todo. Entonces, en este ejemplo, obtendremos un impulso en el SEO del Retraso de la Primera Entrada, LCP y CLS, y no lo obtendremos de FCP. Eso es todo. Y eso es todo lo que tengo para ustedes hoy. Espero que esta charla les haya ayudado a comprender mejor este salvaje mundo de las herramientas de medición del rendimiento y realmente les animo a profundizar un poco más por su cuenta, porque es un tema súper fascinante. Disfruten el resto del evento. Muchas gracias por recibirme y ¡salud!

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

React Advanced Conference 2022React Advanced Conference 2022
25 min
A Guide to React Rendering Behavior
Top Content
React is a library for "rendering" UI from components, but many users find themselves confused about how React rendering actually works. What do terms like "rendering", "reconciliation", "Fibers", and "committing" actually mean? When do renders happen? How does Context affect rendering, and how do libraries like Redux cause updates? In this talk, we'll clear up the confusion and provide a solid foundation for understanding when, why, and how React renders. We'll look at: - What "rendering" actually is - How React queues renders and the standard rendering behavior - How keys and component types are used in rendering - Techniques for optimizing render performance - How context usage affects rendering behavior| - How external libraries tie into React rendering
Vue.js London Live 2021Vue.js London Live 2021
34 min
Everything Beyond State Management in Stores with Pinia
Top Content
When we think about Vuex, Pinia, or stores in general we often think about state management and the Flux patterns but not only do stores not always follow the Flux pattern, there is so much more about stores that make them worth using! Plugins, Devtools, server-side rendering, TypeScript integrations... Let's dive into everything beyond state management with Pinia with practical examples about plugins and Devtools to get the most out of your stores.
React Summit 2023React Summit 2023
32 min
Speeding Up Your React App With Less JavaScript
Too much JavaScript is getting you down? New frameworks promising no JavaScript look interesting, but you have an existing React application to maintain. What if Qwik React is your answer for faster applications startup and better user experience? Qwik React allows you to easily turn your React application into a collection of islands, which can be SSRed and delayed hydrated, and in some instances, hydration skipped altogether. And all of this in an incremental way without a rewrite.
Vue.js London Live 2021Vue.js London Live 2021
20 min
One Year Into Vue 3
Top Content
Vue 3 may still sound new to many users, but it's actually been released for over a year already. How did Vue 3 evolve during this period? Why did it take so long for the ecosystem to catch up? What did we learn from this process? What's coming next? We will discuss these questions in this talk!
Vue.js London Live 2021Vue.js London Live 2021
8 min
Utilising Rust from Vue with WebAssembly
Top Content
Rust is a new language for writing high-performance code, that can be compiled to WebAssembly, and run within the browser. In this talk you will be taken through how you can integrate Rust, within a Vue application, in a way that's painless and easy. With examples on how to interact with Rust from JavaScript, and some of the gotchas to be aware of.

Workshops on related topic

React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Featured WorkshopFree
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
Vue.js London Live 2021Vue.js London Live 2021
169 min
Vue3: Modern Frontend App Development
Top Content
Featured WorkshopFree
The Vue3 has been released in mid-2020. Besides many improvements and optimizations, the main feature of Vue3 brings is the Composition API – a new way to write and reuse reactive code. Let's learn more about how to use Composition API efficiently.

Besides core Vue3 features we'll explain examples of how to use popular libraries with Vue3.

Table of contents:
- Introduction to Vue3
- Composition API
- Core libraries
- Vue3 ecosystem

Prerequisites:
IDE of choice (Inellij or VSC) installed
Nodejs + NPM
JSNation 2023JSNation 2023
170 min
Building WebApps That Light Up the Internet with QwikCity
Featured WorkshopFree
Building instant-on web applications at scale have been elusive. Real-world sites need tracking, analytics, and complex user interfaces and interactions. We always start with the best intentions but end up with a less-than-ideal site.
QwikCity is a new meta-framework that allows you to build large-scale applications with constant startup-up performance. We will look at how to build a QwikCity application and what makes it unique. The workshop will show you how to set up a QwikCitp project. How routing works with layout. The demo application will fetch data and present it to the user in an editable form. And finally, how one can use authentication. All of the basic parts for any large-scale applications.
Along the way, we will also look at what makes Qwik unique, and how resumability enables constant startup performance no matter the application complexity.
React Day Berlin 2022React Day Berlin 2022
53 min
Next.js 13: Data Fetching Strategies
Top Content
WorkshopFree
- Introduction- Prerequisites for the workshop- Fetching strategies: fundamentals- Fetching strategies – hands-on: fetch API, cache (static VS dynamic), revalidate, suspense (parallel data fetching)- Test your build and serve it on Vercel- Future: Server components VS Client components- Workshop easter egg (unrelated to the topic, calling out accessibility)- Wrapping up
Vue.js London Live 2021Vue.js London Live 2021
117 min
Using Nitro – Building an App with the Latest Nuxt Rendering Engine
Top Content
Workshop
We'll build a Nuxt project together from scratch using Nitro, the new Nuxt rendering engine, and Nuxt Bridge. We'll explore some of the ways that you can use and deploy Nitro, whilst building a application together with some of the real-world constraints you'd face when deploying an app for your enterprise. Along the way, fire your questions at me and I'll do my best to answer them.
React Advanced Conference 2023React Advanced Conference 2023
148 min
React Performance Debugging
Workshop
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)