CLS de 0,4 a 0,06 en un flujo de reserva de vacaciones
Los layout shifts estaban en el flujo de reserva, y la mayoría ocurrían después de la primera carga de la página.
Una single page application con un flujo de reserva que se desplazaba
Prijsvrij es una web holandesa de viajes: buscar, comparar y reservar vacaciones. Todo el sitio es una single page application, y el mismo equipo gestiona Prijsvrij.be y D-reizen.
Pasé dos días de cuatro horas en sus oficinas. El primer día audité la web. El segundo revisé los resultados con el equipo y expliqué, paso a paso, cómo resolver primero los problemas más urgentes.
La primera pantalla, el flujo de reserva y los clics
La mayoría de los layout shifts ocurrían en soft navigations: la app cambia el contenido sin cargar una página nueva. Un análisis de Lighthouse en la página de inicio nunca los ve. Los visitantes reales que avanzan en una reserva, sí; y CrUX contabiliza esos layout shifts en la URL que abrieron primero.
Entregué la auditoría a finales de marzo de 2026 y la repasé con sus desarrolladores en Den Bosch el 15 de abril y online una semana después. El CLS fue la parte difícil, con más causas de lo habitual en una arquitectura así. Sus desarrolladores lo solucionaron en las tres webs, y en mayo el CLS en desktop pasó a verde en todas ellas.
Una mañana de junio, su front-end lead me escribió. Llevaba semanas haciendo ajustes en prijsvrij.nl a partir de los datos de CoreDash a través de su conexión con Claude Code, y las gráficas iban en la dirección correcta. ¿Se podía meter también D-reizen? En menos de una hora, tanto D-reizen como Prijsvrij.be estaban ya en CoreDash.
Lo siguiente es el INP. Cuando lo revisé a finales de junio, reconocí el patrón: lo he visto muchas veces y se corrige con un plan paso a paso probado, siempre que cada paso se ejecute con total precisión. Eso resuelve la mayor parte. Solo entonces asoman los problemas de fondo, que siempre son menores. Así que propuse trabajar de forma más práctica: cambios pequeños y quirúrgicos, menos teoría y más acción. En julio nos reunimos en sus oficinas, comida incluida, y nos seguimos viendo cada trimestre.
El LCP en móvil sube durante las vacaciones, cuando gran parte del tráfico viene de usuarios que están de viaje. Se mantiene muy por debajo de los 2,5 segundos y ya está bajando de nuevo.
Una animación de carga solo traslada el layout shift
La animación parecía cubrir la espera. El layout shift se producía en el momento en que dejaba paso a los detalles del vuelo.
El tracking en el clic penaliza cada clic
Una etiqueta en el handler del clic se ejecuta antes de que la pantalla pueda cambiar. Si se mueve a después de la actualización, el visitante ve el resultado primero y la etiqueta se ejecuta igualmente.
Una single page application cambia constantemente
Cada despliegue añade componentes y etiquetas que la última revisión nunca vio. Por eso vuelvo cada trimestre.
¿Layout shifts en una single page app que Lighthouse nunca ve?
Envíame la URL de tu flujo de reserva o checkout y lo recorreré haciendo clics igual que un visitante, soft navigations incluidas.
O mira la consultoría. Más resultados en mi página de clientes.
