Core Web Vitals - ¿Qué, Por qué y Cómo?

Hola y bienvenidos a mi sesión sobre el núcleo de Vitals, su qué, por qué y cómo, más específicamente. Entonces, esta es una conferencia de testing, y siempre me siento un poco humilde al hablar en conferencias de testing porque ya no estoy tan metido en el espacio de testing. Escribo pruebas cuando escribo mi code, pero probablemente todos ustedes sean más expertos aquí que yo. Sin embargo, probar el rendimiento de su sitio web es algo importante, y el núcleo de Vitals es una herramienta para lograr exactamente eso.

Entonces, creo que tiene sentido discutir estas cosas. Esta noche veremos tres cosas diferentes con ustedes. Primero que nada, hablaremos sobre el rendimiento web, o qué es realmente el rendimiento de un sitio web. Hablaremos sobre el núcleo de Vitals, y también hablaremos sobre cómo el núcleo de Vitals contribuirá a una búsqueda de Google en forma de la señal de experiencia de página que se lanzará en mayo. Por lo tanto, también hay algunas implicaciones de SEO o implicaciones de optimización de motores de búsqueda de esto también.

Entonces, comencemos con qué es el rendimiento de un sitio web. Intuitivamente, todos sabemos la respuesta a esta pregunta es un sitio web rápido y agradable para usar o no. Pero si quieres comparar eso entre sitios, e incluso entre diferentes versiones del mismo sitio, se vuelve mucho más complicado, porque quieres algo que puedas comparar y seguir con el tiempo, y las mediciones intuitivas realmente no ayudan y no marcan esa casilla. El objetivo es cuantificarlo, tener algún tipo de número o métrica que podamos obtener que nos diga si un sitio web es rápido y agradable para un usuario usar o no. Como veremos en esta charla, esto ha evolucionado con el tiempo y continúa evolucionando incluso hoy a medida que nuestra comprensión de lo que hace que un sitio web sea rápido, eficiente y agradable para los usuarios cambia la web y el tipo de sitios web que construimos están cambiando. No habrá una respuesta fácil. Esa es una especie de alerta de spoiler. Pero echemos un vistazo a esto.

¿Cómo podríamos cuantificar el rendimiento de la página web? Probablemente una de las primeras métricas ha sido el tiempo hasta el primer byte. Mediríamos cuánto tiempo tarda en llegar el primer byte desde el servidor a nuestro ordenador o dispositivo y en realidad el navegador puede entonces empezar a analizar y eventualmente renderizar la página.

Y históricamente, esto ha tenido mucho sentido. Así, en los sitios web clásicos, como aquí, en este caso de example.com, nuestro navegador haría una solicitud, el servidor web respondería con el HTML, y luego el contenido sería visible en el navegador. Hay grandes diferencias y hay algunas cosas y factores que podemos influir como propietarios y desarrolladores de sitios web para asegurarnos de que esto sigue siendo rápido. Como asegurarnos de que nuestro servidor es rápido, tiene suficiente memoria, tiene suficiente capacidad, tiene un buen ancho de banda de red. También podemos asegurarnos de que el servidor está lo suficientemente cerca, físicamente cerca, porque simplemente lleva tiempo físicamente para que los datos como impulsos eléctricos o de luz viajen. Si estoy aquí en Suiza, el servidor está en Australia, entonces esto podría llevar un tiempo hasta que los datos hayan llegado a Australia y vuelvan. Podría perderse en el camino y entonces tendría que ser retransmitido. Así que esto puede llevar significativamente más tiempo que cuando el servidor está, por ejemplo, en mi propia ciudad, vivo cerca de un centro de datos. Así que tal vez si está ubicado allí, entonces literalmente no lleva tiempo en absoluto. Va a ser realmente, realmente rápido. Y así el tiempo hasta el primer byte será mucho más corto de lo que sería con un servidor en Australia.

Pero, ¿es esta una buena métrica exhaustiva? ¿Es todo lo que necesitamos para cuantificar si un sitio web es rápido y agradable? No. Y eso es en parte porque la arquitectura del sitio web ha cambiado con el tiempo, pero también porque el ancho de banda y las velocidades de conexión no son necesariamente el mayor cuello de botella. Así que vamos a mirar dos sitios web. Abro ambos sitios web en la misma máquina, en la misma ubicación física, al mismo tiempo. Tal vez tengo dos máquinas una al lado de la otra conectadas a la misma conexión a internet, realmente no importa. Voy a A.example.com y B.example.com, y asumimos que estos son servidores completamente separados y aplicaciones web completamente separadas. Así que estas solicitudes salen y A.example.com tarda un rato. Tal vez es como un programa clásico de PHP o Java o Python o Ruby que necesita ejecutarse en el servidor. Tal vez es una aplicación renderizada en el servidor que necesita hablar con un montón de backends y APIs y bases de datos para realmente obtener los datos y luego compilar el HTML antes de enviarlo por el cable, realmente no importa. El punto es que lleva un momento, no importa cuánto dure este momento, simplemente lleva un momento. Mientras que B.example.com, por otro lado, ha recibido la solicitud, responde inmediatamente y el tiempo hasta el primer byte ha llegado. Y es HTML, dice carga este pedazo de JavaScript. Y ahora, al segundo siguiente, B.example.com responde con el HTML completo, ha hecho todas las cosas que necesita hacer en el servidor, y mi navegador me muestra el sitio web, mientras que con B.example.com, no estamos en la etapa en la que obtenemos el App.js, que luego vuelve y probablemente empieza a renderizar o a ejecutar el JavaScript. Una vez que el JavaScript empieza a ejecutarse, descubre, oh, necesitamos hacer este montón de solicitudes de API y estas vuelven, mientras que el navegador todavía no tiene nada sustancial que mostrar al usuario. Ahora, ¿cuál de estos dos sitios web es mejor, más agradable y rápido, según un usuario que mira ambas ventanas del navegador? Bueno, muy claramente, A.example.com, pero si recuerdas, originalmente, según la métrica del tiempo hasta el primer byte, A.example.com era el más lento, tardó más hasta que recibimos el primer byte de la respuesta, pero cuando lo recibimos, la respuesta fue más completa que la otra respuesta. Así que el tiempo hasta el primer byte no es suficiente en estos días y realmente no ha sido una métrica útil. Sigue siendo relativamente útil porque te ayuda, si ves, como, oh mi sitio web es lento y ves que, en realidad, el renderizado en sí es realmente rápido y no tenemos que esperar tanto hasta que las cosas se pintan, es solo el tiempo de conexión y el tiempo que tarda para que los datos vayan por el cable y vuelvan, entonces ese es el cuello de botella que necesitas solucionar y puedes solucionarlo utilizando un CDN o algo así.

Pero el punto es que, esa métrica no es suficiente. Si solo miras el tiempo hasta el primer byte y dices, ¿qué? Mi servidor respondió en 0,1 segundos y los data estuvieron allí en unos 5, 0,5 segundos. ¿Cómo puede ser esto lento? Podrías perderte algo. Y es por eso que hemos mirado muchas, muchas métricas, por ejemplo, el índice de velocidad donde intentamos averiguar, bueno, no solo cuándo está el sitio web? ¿Cuándo se ha completado en su mayoría la parte de la red? Pero cuándo empiezan a aparecer cosas y cuánto tiempo tarda en llegar a una casi completa visualización con el tiempo? Luego miramos la primera pintura completa del contenido. ¿Cuánto tiempo tarda en hacerse visible el primer bit del contenido en la ventana del navegador disculpa.

Y luego tuvimos toneladas de otras métricas con el tiempo para rastrear diferentes aspectos. Pero no se trata solo de cuándo empiezan a aparecer las cosas. Imagina que tienes una tienda en línea para pizzas, quieres que te entreguen pizza en tu lugar. Aparece realmente rápido. El menú está ahí en un abrir y cerrar de ojos, fantástico. Pero entonces estás como, quiero esta pizza, quiero esta pizza, hola, quiero esta pizza. Haces clic, clic, clic, clic, clic. Y después de cinco segundos, de repente tienes cien pizzas en tu carrito. Eso tampoco es agradable. También miramos otras métricas como el tiempo para interactuar. ¿Cuándo puedo empezar a interactuar realmente con el contenido, y muchas otras métricas.

Y esto ha evolucionado con el tiempo en intervalos aleatorios, parece. En algún momento, alguien dijo, en realidad, sabes qué, esta métrica realmente no refleja lo que buscábamos o lo que los usuarios experimentaban. Se nos ocurrió esta nueva métrica. Y luego alguien más dijo, esa es una gran métrica, pero también necesita básicamente tener en cuenta este otro aspecto, como dije, por ejemplo, la interactividad. Y así, no solo tenemos una métrica que miramos, sino que miramos un conjunto de métricas. Lo que desafortunadamente, también hace esto más complicado, no solo para entender, sino también para comunicarse con otros.

Entonces, si estás comunicándote con los usuarios, y dices, como, tienes una puntuación de Lighthouse de 100 de 100, eso realmente no significa mucho para ellos. Sin embargo, podrían decir como, oh, solo es 80 de 100 puntos posibles. Eso todavía no dice mucho. ¿Son realmente un problema esos últimos 20 puntos? ¿O es solo algo cosmético? Entonces, medir el performance es en realidad un gran challenge, resulta. Una cosa es que queremos que las métricas sean relativamente estables, pero también lo suficientemente finas y sensibles para realmente detectar problemas cuando ocurren. Teníamos una métrica llamada primer dolor significativo que intentaba averiguar cuándo el significativo parte del contenido estaba apareciendo. Y eso generalmente era muy inestable. Eso significa que tendrías el mismo sitio web, medirías tres veces, tú obtendrías tres resultados diferentes sin cambiar nada en las circunstancias. Entonces eso no es realmente útil. Quieres una métrica que sea comparable en el tiempo y más o menos estable. Nunca será 100% estable, pero no quieres elegir las más sensibles. No quieres elegir las más bruscas donde no te gusta el tiempo hasta el primer mordisco. Es una métrica muy, muy amplia y brusca. Realmente no refleja las cosas tampoco. Y también, estas métricas realmente necesitan reflejar la verdadera user experience. Ya dije eso con el tiempo para interactuar si necesitábamos una forma de rastrear realmente estas cosas también. Además, nos gustaría que los data pudieran generarse en entornos de laboratorio, donde podemos ejecutar estas cosas de forma automatizada y con cosas que no necesariamente ya son públicas. Si solo podemos recopilar datos de usuarios reales, eso es un poco complicado. Pero también sería bueno obtener datos de usuarios reales, para tener una idea de cómo esto realmente se ve en las máquinas y conexiones de personas reales. Porque nosotros, con nuestras computadoras de alta gama y buena conexión a internet rápida y estable, podríamos no ser el grupo objetivo de nuestro sitio web y luego las personas en los teléfonos, en conexiones inestables podrían tener una experiencia muy, muy diferente. Sería genial si nuestras métricas pudieran medirse en ambos contextos.

Otra gran cosa fue que a medida que cambiábamos las métricas, porque nuestra comprensión de performance cambió con el tiempo, podrías terminar trabajando en mejorar una métrica y luego descubrir que esta métrica cayó en desuso y luego hemos mirado otras métricas y ahora estás como, ooh, nuestra puntuación está aumentando constantemente y luego cae y estás como, ¿por qué? ¿Hemos hecho algo mal? Lo que también te pone en la incómoda posición de que a quien estás informando podría preguntar por estas métricas y luego si tus métricas ahora son más bajas de lo que han sido cuando comenzaste la iniciativa para hacer las cosas más rápidas, eso podría no ser muy cómodo. Entonces necesitábamos cambiar algunas cosas. Y descubrimos que un enfoque sería básicamente obtener signos vitales para la web.

Estos se llaman core web vitals. Pero, ¿qué son estos? Bueno, básicamente son tres métricas para que los desarrolladores web, probadores y SEOs miren para averiguar cómo es la user experience en términos de performance en cada página y para medir eso y trabajar de manera confiable en mejorarlos también.

Los data ya están en prácticamente todas las herramientas que proporcionamos en Google. Por lo tanto, está en Lighthouse, que está en las DevTools de Chrome. Es PageSpeed Insights. Está en el informe de vitales web de la Console de búsqueda de Google. También está WebPageTest. Y también están las APIs de JavaScript en Chrome que puedes usar para medir estas cosas y la configuración del usuario real.

Los objetivos para los umbrales que estamos utilizando para juzgar si los sitios web están funcionando bien, necesitan mejora o están funcionando mal, se basan en data de campo que hemos recopilado y analizado. Por lo tanto, estas métricas pueden y ya están siendo alcanzadas por muchos sitios web. Aunque es posible que no necesariamente alcances los objetivos todavía, puedes lograrlos. Eso es definitivamente posible. Y también para solucionar el problema de los postes de gol en movimiento, los actualizaremos aproximadamente cada año. Entonces los publicamos en mayo del año pasado, 2020. Y probablemente daremos una actualización sobre ellos en Google IO este año también. Y luego, nuevamente, será aproximadamente una cadencia anual para nosotros revisar los umbrales y las métricas.

Entonces, ¿cuáles son estas tres métricas que componen las core web vitals? La primera cosa mide la completitud visual. Entonces, ¿cuánto tiempo tarda hasta que realmente veo lo que me importa? ¿Cuál es el contenido principal? ¿Cuánto tiempo tarda en aparecer? Eso se mide con la métrica de Largest Contentful Paint. Es básicamente el tiempo de carga visual que habíamos medido con otras cosas antes. Y una buena medida sería menos de 2,5 segundos. Si estás haciendo visible tu contenido principal dentro de 4 segundos, eso está en la zona de mejora. Todo lo que tarda más de 4 segundos tiene un impacto en cómo los usuarios perciben tu sitio. Por lo tanto, te recomendamos que hagas el sitio web más rápido entonces.

La segunda métrica, como insinué con el ejemplo de la Pizzería, es cuánto tiempo tarda hasta que puedo interactuar realmente con la aplicación web. Medimos eso en el primer retraso de entrada. Quieres asegurarte de que la página responde a las entradas del usuario, puedes abarcar eso al usar menos JavaScript o desplazarlo fuera del hilo principal o retrasarlo de otra manera. Y quieres estar por debajo de los 100 milisegundos porque eso se siente muy inmediato o básicamente para el cerebro humano, mientras que el retraso de 300 milisegundos se siente un poco lento, pero aún relativamente instantáneo. Todo lo que tarda más eventualmente causará una desconexión o una sensación de desconexión entre la acción y la reacción. Así que eso es algo a lo que también quieres prestar atención.

Por último, pero no menos importante, también queremos asegurarnos de que el contenido de la página es visualmente estable. ¿Qué significa eso? Bueno, significa ¿cuánto se mueve? Probablemente lo sepas si estás en tu teléfono o en tu ordenador, y ves como el sitio web te muestra un botón y quieres interactuar con ese botón. Pero entonces, antes de que puedas hacer clic en ese botón, algo más se mueve y luego como una nueva cosa está ahí y haces clic en eso y dices, oh no, no quería interactuar con esto. ¿Por qué ocurrió eso? Medimos eso con una nueva métrica llamada cambio acumulativo de diseño. Y es básicamente cuánto del contenido se desplazó y cuánto se desplazó. Así que ese valor debería estar por debajo de 0,1 porque todo lo que está entre 0,1 y 0,25 se considera aceptable. Todo lo que es más que eso definitivamente se considera un problema. ¿Qué son estos valores? Para ser justos, realmente no he encontrado la unidad que debería usar porque no es realmente porcentaje pero básicamente la forma en que lo calculas es cuánto de la página se ve afectada por el cambio y cuánto cambia. Así que en este caso, por ejemplo, tenemos un sitio web que tiene dos mitades, la mitad gris y la mitad verde. Después de un tiempo, un botón aparece en medio de la página, lo que significa que toda la mitad inferior se desplaza. Así que el 50% de la página se ve afectado por el cambio. El botón y algún espacio que introduce es aproximadamente el 14% de la página. Así que se ve afectado por el 14%. Así que podemos multiplicar el 50% que es el área afectada por el 14% que se desplaza. Y eso nos da el 7% no es realmente porcentaje pero como 0,07 es el valor que obtenemos si multiplicamos 0,5 con 0,14. Así que 0,07 eso estaría dentro del rango aceptable en realidad. Suponiendo que este botón ahora estaría en la parte superior de la página, todo en la página se desplazaría.

Entonces, un 100% de ello cambiaría. Probablemente todavía estaría cambiando en un 14%, por lo que sería 0.14, que ya está por encima del umbral. Así que puedes ver que tanto las grandes cantidades de espacio que se toman después del hecho o después de la primera renderización, como un cambio que mueve todo en la página, ambos son considerados como cambios problemáticos de todos modos.

¿Qué puedes hacer con respecto a Core Web Vitals? Web.dev.vitals tiene mucha información. Aprende lo que quieras aprender sobre estas métricas, comprende lo que hacen, cómo se miden y cómo puedes mejorarlas. Es muy, muy útil saber cómo funciona esto. Prueba todas tus diferentes versiones de páginas. Si tienes una versión móvil, de escritorio y AMP de tu contenido, entonces prueba las tres o cualquier combinación. Mira cómo integrarlo en tu flujo automatizado porque eso es realmente, realmente útil. También tiene impacto en Google Search o tendrá impacto en Google Search.

Habrá una nueva señal llamada Experiencia de Página. En mayo de 2021, queremos lanzar esta nueva señal de clasificación que se compone de señales de clasificación existentes. Tomamos cosas como la amigabilidad móvil, la navegación segura, HTTPS e intersticiales intrusivos que ya son factores de clasificación y eliminamos la variación de velocidad de página propietaria que usamos para medir en la clasificación con las mediciones de Core Web Vitals y combinamos estas en una señal llamada la señal de Experiencia de Página. La velocidad de página y la experiencia del usuario móvil no son nuevos factores de clasificación. Han estado antes, por lo que no es algo de lo que debamos preocuparnos demasiado. Es solo algo de lo que debemos estar conscientes. Y tanto la velocidad de página utilizando Core Web Vitals como los otros que acabo de mencionar formarán esta nueva señal de Experiencia de Página que ocurrirá en mayo.

Una de las ventajas es que una vez que se haya lanzado esta señal de Experiencia de Página, sabremos cuán rápidas son las diferentes páginas y ya no requeriremos que AMP sea, bueno, AMP ya no será un requisito para aparecer en el carrusel de las mejores historias. Si eres un sitio nuevo y quieres tener tus artículos en el carrusel de las mejores historias, una vez que se haya lanzado la señal de Experiencia de Página, AMP ya no será un requisito para aparecer allí más.

¿Qué puedes hacer para estas cosas? Si las personas en tu organización están preocupadas por la actualización de la Experiencia de Página, no te preocupes por ello. No es como una gran actualización. Es una actualización, pero no es la más grande que hemos hecho. Comprueba tus páginas. Asegúrate de que no haya problemas con Core Web Vitals, que no haya problemas de amigabilidad móvil ni problemas de navegación segura. Puedes usar la Console de búsqueda. Es una herramienta gratuita que hemos puesto a disposición. Puedes ir a search.google.com slash console. Regístrate, obtén una idea de cómo están funcionando tus páginas y utiliza el informe de Core Web Vitals así como la Prueba de amigabilidad móvil para descubrir dónde hay áreas de mejora y trabaja en ellas. Si quieres aprender más, no dudes en contactarnos en Twitter en googlesearchc o contactarme en Twitter en geekonoa. También puedes consultar nuestra documentation en developers.google.com slash search, que tiene mucha información.

Y también tenemos un canal de YouTube con horarios de oficina regulares en youtube.com slash google search central. Con eso, me gustaría decir muchas gracias por ver y escuchar y traer sus preguntas.

Estoy realmente emocionado de escuchar lo que estás haciendo. Martin, hey, gracias por unirte a nosotros. ¿Cómo estás? Hola. Sí, oh, estoy bastante bien. Quiero decir, considerando todo, todavía estoy bien, supongo. Sí, ¿cómo estás? Bien. Me alegra oír eso. Sí, muy bien, muy bien. No puedo quejarme. Quiero decir, han sido dos días encantadores aquí en TestJS Summit. Así que cualquier cosa que suceda en la vida, la olvidas con días de conferencia tan agradables.

Vamos a pasar a las preguntas de nuestra audiencia. Así que prepárate en tu asiento. Vamos a ir... Bueno, la primera pregunta es de nuestro invitado, Yanni. Y pregunta, completitud visual en 2 1⁄2 segundos, pero primera entrada en 100 milisegundos. ¿Es realmente factible tener algún tipo de entrada efectiva si el contenido principal aún no se ha cargado? ¿O la métrica de la primera entrada mide el tiempo entre el usuario haciendo clic y la entrada apareciendo? No entiende muy bien qué es exactamente lo que se mide allí.

Esa es una pregunta brillante. Así que la idea general con el FID es más o menos. ¿Qué problema estamos tratando de abordar? El problema que estamos tratando de abordar con esto es el hecho de que muchas páginas tienen JavaScript que bloquea el hilo principal, lo que significa efectivamente que no puedes usar el hilo principal para nada más que para ejecutar el JavaScript que se ha cargado en el documento. Así que básicamente, el FID 100 milisegundos está mirando la actividad del hilo principal y cuán temprano podríamos potencialmente hacer que el hilo principal haga cosas. Tienes que entender que también la pintura y el diseño y todo eso no sucede en el mapa. De hecho, con el diseño, no estoy ni siquiera 100% seguro y tampoco estoy seguro si cada navegador lo hace igual. Pero al menos la parte de pintura, que tiene mucha influencia en el contenido más grande para pintar, por ejemplo, eso sucede por separado, especialmente la pintura, porque está en el GPU y estoy bastante seguro de que la mayoría de los navegadores están haciendo el diseño en un hilo separado también, pero cualquier JavaScript puede potencialmente bloquear el hilo principal, que es también donde se procesan las interacciones y las entradas. Así que quieres salir del hilo principal lo más temprano posible, o podrías querer amortiguar las cosas o podrías querer descargar mucho trabajo en trabajos más largos en JavaScript web workers, por ejemplo, que por cierto, es una técnica muy subutilizada. Así que eso es más o menos lo que estamos tratando de averiguar aquí. ¿Qué tan rápido responde tu sitio web a las entradas? No necesariamente desde la interacción hasta que algo suceda, sino básicamente cuándo serías capaz de empezar a procesar las entradas? Si lo piensas, si tienes un sitio web que empieza a mostrar cosas y tal vez no muestra cosas todavía, pero todavía tienes un montón de secciones que están ocupando espacio ya porque simplemente la pintura aún no ha sucedido y quieres desplazarte porque sabes que quieres estar en algún lugar en medio de la página y te desplazas y no pasa nada, eso no es necesariamente una gran experiencia. Pero en general para lo que estás tratando de hacer, creo que está bien no preocuparse demasiado por esto, preocúpate más por el retraso entre, y eso es difícil de medir desafortunadamente automáticamente, por lo que esta métrica podría mejorarse en el futuro, entre la interacción que sucede y tu code respondiendo porque ahí es donde realmente está la psique.

De nuevo, no es realmente fácil expresar eso en las métricas todavía, desafortunadamente. Bueno, llegarás allí un día Martin, sé que lo harás. No soy lo suficientemente inteligente para eso, eso es algo en lo que necesitan trabajar, las personas inteligentes. Simplemente actúa, simplemente juega el papel.

Claro, claro, estoy en ello. La siguiente pregunta, y creo que es la última pregunta para la que tenemos tiempo, es de Autogibbon, ¿la métrica CLS está limitada por el tiempo? Por ejemplo, he visto algunas páginas que cambian todo el tiempo mientras las están usando y otras pasan los primeros segundos de carga y equilibran las cosas.

Eso es en realidad, no está limitada por el tiempo hasta donde yo sé. Esa es en realidad una de las mayores quejas sobre esto, porque las aplicaciones de una sola página actualmente tienen un poco de dificultad con CLS porque técnicamente cuando navegas de una vista a otra, tienes un gran cambio de diseño, ¿verdad? Prácticamente todo en la página se ve afectado y cambia mucho. Así que como el CLS se mide a lo largo de la vida de la página en el navegador del usuario, podrías ver altas puntuaciones de CLS cuando en realidad no hay inestabilidad visual. Es simplemente la forma en que suelen funcionar las aplicaciones de una sola página. Actualmente, si vas a Chrome devs, creo que es el nombre de la cuenta. Básicamente la cuenta de Twitter de los desarrolladores de Chrome, encontrarás el enlace a nuestra encuesta donde puedes dar feedback sobre los problemas de CLS, porque sé que esa métrica definitivamente está a punto de ser revisada en profundidad porque no hay un límite de tiempo en CLS que pueda causar altos valores de CLS donde realmente no son un problema de user experience. Sí, parece como hacer trampa. Sí, como dije, eso es todo el tiempo que tenemos para nuestro Q&A cara a cara. Oh, tenemos una más. Una rápida Martin. La pregunta es de Saf. ¿Cómo maneja el cambio de página cosas como las notificaciones de privacidad/cookies, banners y cosas así? Así que eché un vistazo a eso y depende de cómo esté implementado. Si está implementado fuera del resto del flujo de diseño. Así que si básicamente estás posicionando cosas absolutamente encima de él sin que otras cosas cambien, eso no es un cambio de diseño. A menudo muchas soluciones que están en el mercado lamentablemente se implementan de una manera que sí cambia las cosas y entonces eso es un problema. Así que no cambies las cosas si quieres tener una buena puntuación. Si quieres la aprobación de Martin, no cambies las cosas. Bueno, gracias Martin. Para el resto de las preguntas, tendrás que ir a la sala de conferencias de Martin. Va a ir al chat espacial, haz clic en el enlace de abajo en el horario y encontrarás a Martin allí. Martin, gracias. ¡Sí! Encantado de verte de nuevo. Muchas gracias. Saltando al chat espacial. Muchas gracias. Adiós.