Cuando publicamos nuestras mediciones de 36 páginas web de hoteles dominicanos, encabezamos con los números que sostenían el argumento: una puntuación mediana de PageSpeed de 29, una mediana de 17 segundos para mostrar el contenido principal, y el hallazgo de que los pequeños hoteles independientes superaron a las grandes cadenas de resorts por más de dos a uno. Un estudio necesita una columna vertebral, así que mucho de lo que medimos no entró.

Parte de lo que dejamos fuera es más útil que lo que publicamos — incluido un hallazgo que contradice el consejo que da todo desarrollador web, y una medición que nos mintió en silencio. Aquí está el resto de los datos.

Las imágenes no son el problema

Este es el hallazgo que más nos sorprendió, y socava el consejo estándar.

Pregúntale a cualquiera por qué una página web es lenta y te dirán que comprimas las imágenes. Es lo primero a lo que todos recurren, nosotros incluidos. Pero en este conjunto de datos es mayormente falso:

• Las imágenes representaron una mediana del 27% del peso total de la página

• En 28 de 36 sitios, las imágenes eran menos de la mitad del peso total

Lo que significa que en el sitio hotelero típico que medimos, aproximadamente tres cuartas partes de lo que descarga el visitante no son fotografías. Es código — JavaScript, scripts de rastreo, widgets de chat, motores de reserva, gestores de etiquetas, herramientas de personalización, analítica.

Eso cambia el arreglo por completo. No puedes comprimir tu salida de un problema que no son las imágenes. Optimizar la fotografía sigue importando y lo seguiríamos haciendo, pero en estos sitios atiende una cuarta parte del peso y deja intactas las otras tres. El trabajo real es quitar, y quitar es un problema organizacional: cada uno de esos scripts fue agregado deliberadamente, por alguien, por una razón que tenía sentido en su momento. El trabajo de nadie es sacarlos después.

Catorce segundos de navegador congelado

El Total Blocking Time mide cuánto tiempo una página no responde mientras el navegador procesa JavaScript — el período en que los toques no hacen nada y la página parece trabada.

• Mediana: 1.67 segundos

• Media: 3.05 segundos

• Peor medición: 14.55 segundos

Nueve de 36 sitios bloquearon más de tres segundos. Seis bloquearon más de cinco.

Catorce segundos y medio merece una pausa. Eso es un visitante tocando un botón de menú y no obteniendo nada, repetidamente, en el sitio de un hotel con ingresos reales y un departamento de marketing real. Nadie en ese hotel lo sabe, porque en una computadora de oficina con buen Wi-Fi el problema es casi invisible. Solo existe en el teléfono que tu cliente realmente tiene en la mano.

Cosas moviéndose mientras lees

El Cumulative Layout Shift mide cuánto salta una página mientras carga — el efecto en que vas a tocar algo y se mueve de debajo de tu dedo.

El umbral de Google para "bueno" es 0.1. Catorce de 36 sitios lo excedieron, y uno puntuó 1.000, que es aproximadamente el peor resultado posible — una página cuyo contenido todavía se reacomoda mientras intentas usarla.

Esta es la menos comentada de las métricas de rendimiento y una de las más hostiles al usuario. También suele ser barata de arreglar: la mayor parte del desplazamiento viene de imágenes y anuncios cargando sin espacio reservado, y decirle al navegador qué tamaño tendrán las cosas antes de que lleguen es un cambio técnico pequeño.

Accesibilidad: la falla silenciosa

Corrimos puntuaciones de accesibilidad junto a las de rendimiento y luego no las usamos, porque la historia de la velocidad era más fuerte. Merecen su propia mención.

• Media: 81 sobre 100

• 29 de 36 puntuaron menos de 90

• 17 de 36 puntuaron menos de 80

• Solo dos sitios puntuaron 100 perfecto

Estas no son fallas exóticas. Son botones sin etiquetar, contraste de color insuficiente, texto alternativo ausente, campos de formulario sin etiqueta asociada — lo ordinario. Importa por la razón obvia, que es que las personas con discapacidad visual, dificultades motoras o lectores de pantalla también son clientes. Y también importa por una menos obvia: muchas señales de accesibilidad son las mismas que usan los buscadores para entender una página. El texto alternativo describe una imagen a un visitante ciego y a Google. Una estructura de encabezados adecuada ayuda a un lector de pantalla y a un rastreador.

Los hoteles pequeños puntuaron mejor aquí también — 84.5 contra 80.9 de los resorts grandes — que es el mismo patrón que mostraron los datos de rendimiento.

Todos los motores de reserva directa estaban en el dominio de otro

Detectamos motores de reserva en siete sitios: tres con Hotetec, dos con SynXis, uno con Paraty, uno con Beds24. Todas son plataformas legítimas de reserva hotelera.

Aquí está la parte que vale notar: los siete estaban alojados en el dominio del proveedor, no del hotel. Cero de siete corrían el flujo de reserva en su propio sitio.

En la práctica eso significa que un huésped que encuentra un hotel, navega sus habitaciones y hace clic en "Reservar" es transferido a una dirección web distinta para completar la transacción — un momento donde la marca cambia, la URL cambia, y la confianza se pone a prueba. Es normal en la industria y funciona. Pero combinado con nuestro hallazgo publicado de que solo un tercio de estos hoteles ofrece reserva directa siquiera, el panorama es que incluso los hoteles que lo hacen bien lo hacen sobre infraestructura alquilada.

Quince hoteles llevan marcado que ya no hace nada

Los datos estructurados estaban extendidos — el 86% de los sitios llevaba JSON-LD. Pero 15 de 36 sitios todavía llevan marcado FAQPage, que Google retiró en 2026. No produce ninguna función de búsqueda. No se penaliza y no hace daño; simplemente no hace nada.

No lo mencionamos porque le esté costando posicionamiento a alguien. Lo mencionamos porque es un indicador limpio de algo más difícil de medir: ¿cuánto hace que alguien miró este sitio? El marcado de una función que fue retirada es una capa fósil. Te dice que el sitio se configuró una vez, correctamente, por alguien competente — y luego nunca se volvió a revisar.

La medición que nos mintió

Esto es lo más importante de este artículo, y es una advertencia sobre el método más que un hallazgo sobre hoteles.

Volvimos a medir los cuatro resultados más extremos antes de publicar. Un resort grande había puntuado 7 en la primera corrida. En las repeticiones puntuó 19, dos veces. Así que el 7 se excluyó y ningún hotel de bajo rendimiento fue nombrado en el artículo publicado.

Pero una de esas repeticiones hizo algo peor que estar equivocada. Devolvió una puntuación de rendimiento de 100, un Largest Contentful Paint de 0.8 segundos, y un peso total de página de 0.0 MB. Ninguna página había cargado. La herramienta había medido una respuesta vacía y la puntuó como si fuera la página web más rápida del mundo.

Si hubiéramos corrido esa prueba una sola vez, en ese intento, habríamos publicado que ese hotel tenía una puntuación perfecta. Nada en el resultado dice "esto está mal". Se ve como un gran resultado.

La lección se generaliza mucho más allá de nuestro estudio. Cualquier medición que muestre un peso de página cercano a cero debería descartarse en vez de creerse. Y ninguna corrida automática única es base justa para una afirmación pública sobre un negocio específico — que es por lo que nuestro artículo publicado nombró solo al hotel cuya puntuación máxima verificamos dos veces, y describió a todos los de bajo rendimiento de forma anónima.

Publicamos esto porque los estudios que solo muestran sus resultados limpios son menos confiables que los estudios que muestran dónde tembló el instrumento.

Qué haríamos distinto la próxima vez

Tres cosas, dichas claramente:

Medir tres veces, reportar la mediana. Lo hicimos solo para los valores extremos. Debería ser el estándar para cada sitio, y habría atrapado la inestabilidad que encontramos en una propiedad que osciló entre 20 y 50 en dos corridas.

Incluir datos de campo donde existan. Todo aquí es medición de laboratorio — Lighthouse sobre hardware simulado. Donde un sitio tiene suficiente tráfico, Google también publica datos de usuarios reales, que se acercan más a lo que los clientes realmente experimentan.

Medir más que la página de inicio. Probamos solo páginas de inicio. Las páginas de habitaciones y el flujo de reserva son donde un hotel realmente gana dinero, y pueden ser considerablemente mejores o peores.

El hilo que atraviesa todo

Cada hallazgo aquí apunta a lo mismo que encontró el artículo principal: estos sitios se construyeron con competencia y luego se dejaron solos. Los datos estructurados son correctos pero incluyen un tipo retirado. Las fallas de accesibilidad son las rutinarias que cualquier auditoría marcaría. Los scripts se acumulan porque agregar es el trabajo de alguien y quitar no es el de nadie.

Eso no es un problema de diseño, y un rediseño no lo arreglaría — un sitio nuevo dejado solo tres años termina exactamente en el mismo estado. Es un problema de mantenimiento, que es mucho menos interesante y considerablemente más barato de resolver.

Si quieres saber qué está cargando tu propio sitio — los scripts que nadie removió, el marcado que dejó de funcionar, el tiempo de bloqueo que tus clientes sienten y tú no — contáctanos para una consulta gratuita. Lo medimos correctamente, más de una vez, y te decimos qué encontramos.