Velocidad de la web de tu hotel: guía de Core Web Vitals para no técnicos

Piensa en alguien que mira la web de tu hotel desde el móvil, con una conexión regular, en el tren o en la cola del aeropuerto. Si la foto principal tarda en aparecer o el botón de reservar se mueve justo cuando vas a pulsarlo, el visitante vuelve a Booking, donde todo carga rápido.

Esta guía explica, sin jerga, qué mide Google cuando habla de velocidad, cómo comprobar la web de tu hotel en cinco minutos y cuáles son los fallos que más se repiten en webs de alojamientos. Al final tienes una tabla para decidir si basta con arreglos o conviene rehacer.

Qué mide Google: LCP, INP y CLS

Google agrupa la experiencia de carga en tres métricas que llama Core Web Vitals. Cada una responde a una pregunta que se hace cualquier visitante:

Umbrales según Google Search Central y web.dev.

Dos detalles que conviene saber:

• Se mide sobre usuarios reales, en el percentil 75. web.dev recomienda medir el umbral en el percentil 75 de las cargas de página, separando móvil y ordenador. Dicho de otra forma: no vale con que la web vaya bien en tu ordenador de la oficina. Tiene que ir bien para la mayoría de tus visitantes, incluidos los que entran con un móvil normal.
• INP sustituyó a FID. Si lees guías antiguas que hablan de «First Input Delay», están desfasadas: según web.dev, INP pasó a ser una métrica estable de Core Web Vitals en 2024.

En una web de hotel, el LCP suele ser la foto grande de la portada. El INP depende sobre todo de cuánto código se ejecuta en el móvil (motor de reservas, chat, analítica, efectos). El CLS lo provocan las imágenes sin tamaño definido, los banners que aparecen tarde y los widgets que empujan el contenido.

¿Afecta la velocidad al posicionamiento?

Sí, pero con matices. Google dice en su documentación que las Core Web Vitals las usan sus sistemas de clasificación, y recomienda conseguir buenos valores «para tener éxito en la Búsqueda».

Al mismo tiempo, deja claro que no hay una única señal y que la Búsqueda de Google siempre intenta mostrar el contenido más relevante, aunque la experiencia de página sea mediocre.

Traducido a tu hotel: una web rápida no te va a poner por delante de Booking solo por ser rápida. Pero una web lenta te hace perder dos veces: en Google, frente a páginas igual de relevantes y más rápidas, y en la conversión, porque el visitante que espera se va. Lo segundo suele doler más.

Cómo medir la web de tu hotel

Necesitas dos herramientas gratuitas de Google.

1. PageSpeed Insights (pagespeed.web.dev). Pega la dirección de tu portada y pulsa «Analizar». Verás dos bloques:

• Arriba, los datos de usuarios reales. Salen del informe de experiencia de usuario de Chrome y cubren los últimos 28 días. Esto es lo que Google tiene en cuenta como Core Web Vitals. Si tu web tiene poco tráfico, la herramienta usa los datos de todo el dominio o, si tampoco hay suficientes, no muestra nada.
• Abajo, la prueba de laboratorio (Lighthouse): una carga simulada en un dispositivo y una conexión fijos. Da la famosa puntuación de 0 a 100. Según Google, 90 o más es buena, de 50 a 89 necesita mejorar y por debajo de 50 es mala.

La puntuación y las Core Web Vitals no son lo mismo. Puedes tener un 60 en laboratorio y aprobar con usuarios reales, o al revés. Para decidir, mira primero los datos reales; usa el laboratorio para encontrar las causas.

Haz la prueba en la pestaña de móvil, y repítela con la página de habitaciones y con la de reservar, no solo con la portada.

2. Search Console. Si tu web está dada de alta, el informe de Core Web Vitals te dice qué grupos de páginas van bien, cuáles necesitan mejorar y cuáles van mal. Es la forma de ver toda la web de golpe y no página a página.

Los 7 culpables habituales en webs de hotel

Estos son siete puntos que conviene revisar primero en cualquier web de alojamiento, porque casi todas tienen alguno de estos elementos.

1. Fotos enormes

Es lo primero que conviene revisar. A menudo, la foto de la portada sale de la cámara del fotógrafo con varios megas y se sube tal cual. En el móvil se ve a 400 píxeles de ancho, pero el teléfono descarga la imagen entera.

Qué hacer: exportar cada foto al tamaño en que se va a ver, en formatos modernos como WebP o AVIF, y servir versiones distintas para móvil y ordenador.

2. Sliders y vídeos en la portada

El carrusel de seis fotos a pantalla completa, o el vídeo de fondo, es el elemento más pesado de la página y suele ser justo el LCP. Además, muchos sliders se montan con librerías que añaden código.

Qué hacer: una sola foto principal muy buena carga más rápido que seis. Si quieres vídeo, mejor que el usuario lo active.

3. Carga diferida mal aplicada

La carga diferida (lazy loading) es buena para las fotos de más abajo, pero mala para la foto principal. Un artículo de web.dev sobre el tema concluye que cargar en diferido las imágenes de la primera pantalla retrasa el LCP y recomienda cargar esas imágenes de forma inmediata.

Qué hacer: la foto de arriba, carga normal y con prioridad; el resto, en diferido.

4. El widget del motor de reservas

Muchos motores se insertan con un script o un iframe que viene de otro servidor y se carga en todas las páginas, aunque el visitante solo esté mirando el restaurante. Si el buscador de fechas aparece sin un hueco reservado, empuja el contenido al cargar y empeora el CLS.

Qué hacer: reservar el espacio del widget en el diseño (web.dev recomienda reservar espacio para el contenido que llega tarde) y cargar el script completo solo donde hace falta. Hablamos de cómo se integra el motor con la web en la guía sobre cómo elegir motor de reservas.

5. Chat, píxeles y otros scripts de terceros

Chat en directo, widget de reseñas, píxel de Meta, varias etiquetas de analítica, mapa incrustado en la portada, banner de cookies pesado… Cada uno añade código que el móvil tiene que ejecutar, y eso afecta sobre todo al INP.

Qué hacer: haz inventario. Quita lo que nadie usa, carga el mapa solo en la página de cómo llegar y retrasa lo que no sea imprescindible al primer vistazo.

6. Fuentes tipográficas

Tres familias de letra con cinco grosores cada una es mucho peso. Y cuando la fuente llega tarde, el texto cambia de tamaño y desplaza lo demás: web.dev lo cita como causa típica de CLS.

Qué hacer: una o dos familias, solo los grosores que se usan, precargar la principal y definir una fuente de respaldo de medidas parecidas.

7. Plugins y hosting

En webs hechas con WordPress y un tema de hotel, es habitual acumular plugins que cargan su código en todas las páginas, y alojar la web en un servidor compartido barato que tarda en responder. Si el servidor tarda, todo lo demás llega tarde.

Qué hacer: revisar qué plugins siguen haciendo falta, activar caché y valorar un alojamiento mejor o una red de distribución de contenidos (CDN). Si dudas entre seguir con WordPress o cambiar, lo comparamos en WordPress, plantilla o web a medida.

Arreglos rápidos o rehacer la web

No todo exige una web nueva. Esta tabla te ayuda a decidir:

Una regla práctica: si después de los arreglos rápidos sigues en rojo con usuarios reales en el móvil, el problema está en cómo está construida la web, no en una foto.

Lista de comprobación

• La foto principal pesa poco, está en WebP o AVIF y no se carga en diferido.
• Todas las imágenes y el widget de reservas tienen su espacio reservado.
• No hay carrusel ni vídeo automático en la primera pantalla del móvil.
• El chat, los píxeles y el mapa no se cargan antes de lo necesario.
• Una o dos familias tipográficas, con la principal precargada.
• PageSpeed Insights, en la pestaña de móvil, revisado en portada, habitaciones y reservar.
• Informe de Core Web Vitals de Search Console sin URLs en mal estado, o con un plan para arreglarlas.

La velocidad es uno de los puntos que debe cumplir cualquier web de alojamiento; el resto los repasamos en la guía sobre qué necesita una página web para hotel.

Si no tienes tiempo de mirar todo esto, nuestra auditoría web gratuita comprueba la velocidad de tu web y te dice qué está fallando, en un minuto y sin compromiso.