Tu correo de confirmación llega de Booking.com — otra reserva, otro 18% desaparecido. El huésped dormirá en tu cama, desayunará en tu hotel, recordará tu servicio, pero Expedia es propietaria de la relación y se queda con una cuarta parte de los ingresos. Estás pagando a estas plataformas para alquilar acceso a viajeros que ya estaban buscando tu propiedad por nombre. La corrección arquitectónica no es un widget de reservas pegado a WordPress. Es un sistema headless que intercepta el camino de búsqueda a reserva en tres puntos de decisión — y las propiedades que ejecutan este stack reportan desplazar el 38–43% de las reservas de vuelta a canales directos en 90 días. La diferencia aparece en dos lugares: tu margen por habitación y tu capacidad de remarketing sin pagar a las OTAs por datos de huéspedes que generaste.

Pero aquí está lo que he visto funcionar, repetidamente, en hoteles boutique y cadenas de tamaño medio: un sitio web de reservas directas correctamente arquitectado puede desplazar 30-40% del ingreso dependiente de OTA de vuelta a tu canal propio en 12-18 meses. No a través de trucos. A través de ingeniería.

Esto no es un artículo de marketing sobre "solo ofrece una mejor tarifa". Se trata de las decisiones de arquitectura técnica -- desde tu integración del motor de reservas hasta la velocidad de carga de tu página hasta la estructura de tu CMS -- que hacen que las reservas directas sean lo suficientemente sin fricciones para competir con la UX pulida de las OTAs.

Tabla de Contenidos

Hotel Direct Booking Website Architecture That Cuts OTA Commissions 40%

El Costo Real de la Dependencia OTA

Hagamos las matemáticas que mantienen despiertos a los directores generales de hoteles.

Un hotel de 100 habitaciones con 75% de ocupación, $180 ADR, y 65% de las reservas procedentes de OTAs:

Métrica Valor
Ingreso anual de habitaciones $4,927,500
Ingresos procedentes de OTA (65%) $3,202,875
Comisión OTA promedio (20%) $640,575
Procesamiento de tarjeta de crédito en reservas OTA (3%) $96,086
Costo OTA total por año $736,661

Eso es $736K saliendo por la puerta. Ahora imagina desplazar solo el 40% de esas reservas OTA a directo. Ahorrarías aproximadamente $294K anuales. Eso no es un error de redondeo -- esa es una renovación completa presupuestada o dos miembros de personal adicionales.

El reporte Phocuswright 2025 muestra que los hoteles que promedian por encima del 40% de ratio de reservas directas tienen 22% mayor RevPAR que sus competidores dependientes de OTA. No se trata solo de ahorros de comisión. Los que reservan directamente se quedan más tiempo, gastan más en la propiedad, y regresan más frecuentemente.

Por Qué la Mayoría de Sitios Web de Hoteles Fracasan en Reservas Directas

He auditado docenas de sitios web de hoteles, y los mismos problemas aparecen cada vez:

Son lentos. El sitio web promedio de un hotel se carga en 8.2 segundos en móvil (datos de Google de benchmarks de hospitalidad, 2024). Las OTAs se cargan en menos de 2 segundos. Cuando tu sitio tarda cuatro veces más que Booking.com, ya has perdido.

El flujo de reserva es una pesadilla de redireccionamientos. El huésped aterriza en tu hermosa página de inicio, hace clic en "Reservar Ahora", y es enviado a un dominio completamente diferente con un estilo diferente, fuentes diferentes, y una UI que grita 2014. La confianza se evapora.

El CMS es una jaula. La mayoría de sitios de hoteles se ejecutan en temas WordPress monolíticos con constructores de páginas que hacen imposible iterar rápidamente. ¿Quieres hacer una prueba A/B de una nueva ubicación de widget de reservas? Eso será un ciclo de desarrollo de tres semanas.

Sin pensamiento móvil primero. Más del 70% de la investigación hotelera sucede en móvil (Google Travel Insights 2026), y alrededor del 45% de las reservas directas ahora se completan en dispositivos móviles. Sin embargo, la mayoría de sitios de hoteles tratan móvil como una ocurrencia tardía.

Cero personalización. Las OTAs conocen a los visitantes recurrentes, muestran propiedades relevantes, ajustan los mensajes según el historial de búsqueda. Tu sitio de hotel muestra la misma imagen hero a todos.

Estos no son problemas de marketing. Son problemas de arquitectura.

El Stack de Arquitectura de Reservas Directas

Aquí está el stack que recomiendo para hoteles serios sobre ingresos de reservas directas:

Capa Tecnología Recomendada Por Qué
Framework Frontend Next.js o Astro Cargas sub-segundo, SSR para SEO, ISR para precios dinámicos
CMS Sanity, Contentful, o Storyblok Contenido estructurado, multiidioma, edición visual
Motor de Reservas SynXis, Profitroom, o Bookassist API-first, embebible, gestión de tarifas
Integración PMS Mews, Opera Cloud, o Cloudbeds Sincronización de disponibilidad en tiempo real
CDN/Hosting Vercel, Netlify, o Cloudflare Pages Entrega en edge, rendimiento global
Analytics GA4 + Looker Studio + eventos personalizados Atribución de embudo de reserva
Personalización Dynamic Yield o middleware personalizado Reconocimiento de huésped recurrente

El principio clave: desacopla todo. Tu gestión de contenidos, tu motor de reservas, tu presentación frontend, y tu sistema de gestión de propiedades deberían comunicarse a través de APIs pero permanecer independientemente actualizables.

Este es el enfoque de arquitectura headless que construimos en Social Animal para clientes de hospitalidad. Déjame caminar a través de cada capa.

Hotel Direct Booking Website Architecture That Cuts OTA Commissions 40% - architecture

CMS Headless: La Capa de Fundación

El sitio web tradicional de un hotel se ejecuta en un CMS monolítico -- usualmente WordPress con un tema que agrupa contenido, diseño, y widgets de reservas en un desorden enmarañado. Actualizar una cosa arriesga romper otra.

Un CMS headless separa tu contenido de tu presentación. Tu equipo de marketing gestiona descripciones de habitaciones, galerías de fotos, ofertas especiales, y contenido de blog en un editor limpio. Tu frontend obtiene ese contenido vía API y lo renderiza de la forma que tenga sentido para cada contexto -- sitio web, aplicación móvil, tableta en la habitación, incluso señalización digital.

Por Qué Esto Importa para Hoteles Específicamente

Los hoteles tienen relaciones de contenido complejas. Un tipo de habitación se conecta a amenidades, planes de tarifa, fotos, planos de planta, descripciones estacionales, y disponibilidad. Un CMS headless con modelado de contenido estructurado maneja esto nativamente.

En Sanity, por ejemplo, lo modelarías así:

// sanity/schemas/roomType.js
export default {
  name: 'roomType',
  title: 'Room Type',
  type: 'document',
  fields: [
    { name: 'name', type: 'string', title: 'Room Name' },
    { name: 'slug', type: 'slug', options: { source: 'name' } },
    { name: 'description', type: 'blockContent', title: 'Description' },
    { name: 'shortDescription', type: 'text', title: 'Short Description', validation: Rule => Rule.max(160) },
    { name: 'maxOccupancy', type: 'number', title: 'Max Occupancy' },
    { name: 'squareFootage', type: 'number', title: 'Square Footage' },
    { name: 'gallery', type: 'array', of: [{ type: 'image', options: { hotspot: true } }] },
    { name: 'amenities', type: 'array', of: [{ type: 'reference', to: [{ type: 'amenity' }] }] },
    { name: 'ratePlans', type: 'array', of: [{ type: 'reference', to: [{ type: 'ratePlan' }] }] },
    { name: 'bookingEngineCode', type: 'string', title: 'Booking Engine Room Code' },
    { name: 'seo', type: 'seoFields' }
  ]
}

Ese campo bookingEngineCode es crucial -- conecta tu contenido CMS al inventario del motor de reservas, habilitando visualización de tarifas en línea sin redirigir a usuarios.

Soporte Multi-Propiedad

Si eres un grupo hotelero, la arquitectura headless te permite gestionar múltiples propiedades desde una única instancia de CMS mientras despliegas frontends distintos para cada propiedad. El contenido compartido (estándares de marca, información del programa de lealtad) vive en un lugar. El contenido específico de la propiedad se mantiene escoped. Esto es dramáticamente más eficiente que mantener instalaciones separadas de WordPress.

Patrones de Integración del Motor de Reservas

Aquí es donde la mayoría de sitios web de hoteles pierden conversiones. Hay tres patrones de integración, y la diferencia entre ellos vale millones en ingresos.

Patrón 1: Redireccionamiento (El Asesino de Ingresos)

El huésped hace clic en "Reservar Ahora" → el navegador redirige a booking-engine-vendor.com/your-hotel → UI completamente diferente, dominio diferente, señales de confianza diferentes.

Tasa de conversión: típicamente 1.5-2.5%.

Esto es todavía cómo funcionan la mayoría de hoteles, y es terrible. Cada cambio de dominio pierde 20-30% de posibles reservistas (datos del Instituto Baymard sobre abandono de checkout).

Patrón 2: Incrustación en iFrame (Mejor, No Excelente)

El motor de reservas se renderiza dentro de un iframe en tu sitio. Mismo dominio en la barra de direcciones, pero el iframe crea su propio contexto de scroll, no puede coincidir perfectamente con el estilo de tu sitio, y se rompe en móvil más frecuentemente de lo que los proveedores admiten.

Tasa de conversión: típicamente 2.5-4%.

Patrón 3: Integración en Línea API-First (El Objetivo)

Tu frontend llama directamente a la API del motor de reservas. Disponibilidad, tarifas, selección de habitación, y el formulario de reserva se renderizan como componentes nativos en tu sitio. El huésped nunca abandona tu dominio. La UI coincide perfectamente con tu marca. Controlas cada píxel del flujo de reserva.

Tasa de conversión: típicamente 4-7%.

Aquí hay un ejemplo simplificado de Next.js:

// app/api/availability/route.ts
import { NextResponse } from 'next/server'

export async function GET(request: Request) {
  const { searchParams } = new URL(request.url)
  const checkIn = searchParams.get('checkIn')
  const checkOut = searchParams.get('checkOut')
  const guests = searchParams.get('guests')

  const response = await fetch(
    `${process.env.BOOKING_ENGINE_API}/availability?` +
    `propertyId=${process.env.PROPERTY_ID}&` +
    `checkIn=${checkIn}&checkOut=${checkOut}&guests=${guests}`,
    {
      headers: {
        'Authorization': `Bearer ${process.env.BOOKING_ENGINE_KEY}`,
        'Content-Type': 'application/json'
      },
      next: { revalidate: 60 } // Cache for 60 seconds
    }
  )

  const data = await response.json()
  return NextResponse.json(data)
}

No todo motor de reservas soporta este nivel de acceso API. SynXis (Sabre), Profitroom, y Bookassist todos ofrecen APIs REST que habilitan integración profunda. Cloudbeds y Mews están llegando allí. Si tu proveedor actual solo soporta redireccionamiento o iframe, esa es una conversación seria que debes tener.

Hemos construido varias de estas integraciones de motor de reservas API-first usando Next.js y la diferencia de rendimiento es marcada.

Arquitectura de Rendimiento Que Convierte

La investigación de Google específicamente en hospitalidad muestra que una mejora de 1 segundo en el tiempo de carga móvil aumenta las conversiones del sitio web del hotel hasta el 10%. Cuando tu competencia es una OTA sub-2-segundo, cada milisegundo importa.

El Stack de Rendimiento

Generación estática con ISR (Regeneración Estática Incremental). Tus páginas de habitación, páginas acerca de, páginas de comedor -- estas no cambian cada minuto. Genéralas en tiempo de construcción y revalida cada pocas horas. Resultado: carga casi instantánea.

Contenido dinámico renderizado en edge. Comprobaciones de disponibilidad, visualizaciones de tarifas, ofertas personalizadas -- estas necesitan ser frescas. Ejecutalas en funciones edge (Vercel Edge, Cloudflare Workers) cerca del usuario.

Pipeline de optimización de imágenes. Los hoteles son pesados en imágenes por naturaleza. Necesitas:

  • Servicio de formato WebP/AVIF basado en soporte del navegador
  • Dimensionamiento responsivo (no sirvas una imagen hero de 4000px a un teléfono)
  • Carga perezosa debajo del pliegue
  • Placeholders de desenfoque para rendimiento percibido

El componente <Image> de Next.js maneja la mayoría de esto automáticamente. Astro es otra opción excelente aquí, especialmente para hoteles que no necesitan interactividad pesada -- su enfoque de cero-JS-por-defecto entrega puntuaciones de rendimiento insanas.

Métricas objetivo para un sitio web de hotel en 2026:

Core Web Vital Objetivo Por Qué
LCP (Largest Contentful Paint) < 1.5s La imagen/video hero debe cargarse rápido
INP (Interaction to Next Paint) < 150ms Las interacciones del widget de reserva deben sentirse instantáneas
CLS (Cumulative Layout Shift) < 0.05 Sin contenido saltador cuando se cargan tarifas
TTFB (Time to First Byte) < 200ms El hosting en edge hace esto alcanzable

Arquitectura SEO para Reservas Directas en Hoteles

Aquí está la cosa sobre dependencia OTA que nadie habla suficientemente: estás compitiendo con OTAs por tu propio nombre de marca en Google.

Busca "[El Nombre de Tu Hotel] reserva" y verás anuncios de Booking.com, Expedia, y TripAdvisor por encima de tu propio sitio web. Están gastando tu dinero de comisión para interceptar tus posibles reservistas directos.

La respuesta arquitectónica:

Marcado de Datos Estructurados

Implementa marcado de esquema LodgingBusiness, Hotel, y Offer en cada página relevante. Esto habilita resultados enriquecidos -- calificaciones por estrellas, rangos de precio, indicadores de disponibilidad -- directamente en resultados de búsqueda.

{
  "@context": "https://schema.org",
  "@type": "Hotel",
  "name": "Your Hotel Name",
  "starRating": {
    "@type": "Rating",
    "ratingValue": "4"
  },
  "priceRange": "$$",
  "checkinTime": "15:00",
  "checkoutTime": "11:00",
  "makesOffer": [
    {
      "@type": "Offer",
      "name": "Deluxe King Room",
      "priceSpecification": {
        "@type": "PriceSpecification",
        "price": "189",
        "priceCurrency": "USD",
        "unitText": "per night"
      }
    }
  ]
}

Arquitectura del Hub de Contenido

Crea contenido basado en ubicación que capture intención de viaje antes de que el huésped comience a comparar en OTAs:

  • /cosas-que-hacer/ - Guías de atracciones locales
  • /eventos/ - Eventos y conferencias estacionales cercanas
  • /barrios/ - Guías de área para diferentes tipos de viajeros
  • /gastronomía/ - Recomendaciones de restaurantes (incluyendo tu propia F&B)

Cada página se vincula internamente a tipos de habitación relevantes con CTAs de reserva. Esto captura tráfico de búsqueda de embudo superior y lo canaliza hacia reserva directa.

Fundamentos SEO Técnico

  • Etiquetas hreflang programáticas para propiedades multiidioma
  • Generación de sitemap XML que incluye páginas de tipo de habitación, páginas de oferta, y páginas de contenido
  • Gestión de URL canónica (crítica cuando tienes múltiples patrones URL para la misma habitación)
  • Renderización del lado del servidor para todo el contenido (SPAs con renderización del lado del cliente son suicidio SEO para hoteles)

Paridad de Tarifas y Estrategia de Incentivos de Precio

La arquitectura habilita la estrategia, pero aún necesitas una razón convincente para que los huéspedes reserven directamente.

Las restricciones de paridad de tarifas existen en contratos con la mayoría de OTAs, aunque las regulaciones varían por país. La UE ampliamente prohíbe cláusulas estrechas de paridad de tarifas ahora. En los EE.UU., es más turbio.

Lo que siempre puedes hacer:

  • Tarifas solo para miembros: Requiere una inscripción de correo electrónico gratis para ver una tarifa más baja. Esto es técnicamente un "grupo de usuario cerrado" y no viola la mayoría de acuerdos de paridad. Tu arquitectura necesita soportar visualización de tarifa autenticada.
  • Empaquetado de valor agregado: Misma tarifa de habitación, pero los reservistas directos obtienen estacionamiento gratis, checkout tardío, o desayuno. Tu integración del motor de reservas necesita mostrar estos complementos prominentemente.
  • Widget de comparación de precios en tiempo real: Muestra tu tarifa junto a tarifas OTA en tu propia página de reserva. Empresas como Triptease y The Hotels Network proporcionan estos widgets, pero funcionan mejor cuando se integran arquitectónicamente en lugar de ser pegados como scripts de terceros.

Capa de Lealtad y Personalización

Las OTAs tienen motores de personalización masivos. No puedes coincidir con su escala, pero puedes vencerlas en los datos de tu propia propiedad del huésped.

Reconocimiento de Huésped Recurrente

Cuando un huésped anterior visita tu sitio web, tu middleware debería:

  1. Reconocerlos (cookie o sesión autenticada)
  2. Mostrar su tipo de habitación preferido primero
  3. Mostrar una tarifa personalizada (descuento de lealtad)
  4. Rellenar previamente sus detalles de reserva
  5. Mostrar superficialmente ventas cruzadas relevantes basadas en estancias anteriores

Esto requiere una capa de datos de cliente conectando tus perfiles de huésped PMS a tu frontend de sitio web. Un enfoque simple:

// middleware.ts
import { NextResponse } from 'next/server'

export function middleware(request) {
  const guestToken = request.cookies.get('guest_token')?.value
  
  if (guestToken) {
    // Add guest context to request headers for downstream components
    const response = NextResponse.next()
    response.headers.set('x-guest-segment', 'returning')
    return response
  }
  
  return NextResponse.next()
}

Tus componentes de listado de habitaciones entonces se adaptan basados en este contexto. Los huéspedes recurrentes ven tarifas de lealtad. Los visitantes primerizos ven la mejor tarifa disponible con un aviso para unirse al programa de lealtad.

Arquitectura de Captura de Correo Electrónico

Cada visitante que no reserve debería aún entrar en tu ecosistema. Los overlays de intención de salida, signos de alerta de precio, y guías protegidas por contenido todos sirven este propósito. Pero la implementación técnica importa: estas necesitan cargar de forma asincrónica, no bloquear tu ruta de renderización crítica, y no hundirse tus Core Web Vitals.

Midiendo el Cambio: KPIs que Importan

Necesitas dashboards que rastreen el cambio en mezcla de canal, no solo reservas generales.

KPI Línea Base (Dependiente OTA) Objetivo (12 meses) Objetivo (24 meses)
Ratio de reserva directa 25-35% 40-50% 50-60%
Tasa de conversión del sitio web 1.5-2% 3.5-5% 5-7%
Tasa de conversión móvil 0.8-1.2% 2.5-3.5% 3.5-5%
Tasa de abandono de reserva 75-85% 55-65% 45-55%
Costo por adquisición (directo) N/A $8-15 $5-10
Costo por adquisición (OTA) $35-55 $35-55 $35-55
LCP del sitio web (móvil) 5-8s <2s <1.5s

Nota que tu CPA OTA se mantiene igual -- no estás eliminando OTAs, estás reequilibrando. Las OTAs permanecen valiosas para descubrimiento y llenar inventario en dificultad. El objetivo es asegurar que los huéspedes que ya conocen tu hotel no necesiten reservar a través de un intermediario.

Configura seguimiento de comercio electrónico mejorado en GA4 con eventos personalizados para cada paso de tu embudo de reserva. Si no puedes medir dónde la gente abandona, no puedes arreglarlo.

La Decisión Construir vs. Comprar

Tienes tres caminos:

  1. Soluciones de plantilla (Bookassist, Avvio, Net Affinity) — $500-2,000/mes. Despliegue rápido, personalización limitada. Bueno para hoteles independientes menores de 50 habitaciones.

  2. Construcción headless personalizada — $40,000-150,000 inicio, $2,000-5,000/mes mantenimiento. Control total, integración de motor de reservas API-first, rendimiento máximo. Correcto para hoteles sobre 50 habitaciones o grupos de hoteles donde los ahorros de comisión justifican la inversión.

  3. Híbrido — Comienza con un motor de reservas de plantilla pero construye un frontend headless alrededor. Esto es frecuentemente el punto dulce.

Si estás explorando opción 2 o 3, ese es el tipo de trabajo que hacemos. Hemos construido sitios de hoteles headless que alcanzan tiempos de carga sub-1-segundo y duplicaron ratios de reservas directas dentro del primer año.

Las matemáticas ROI son simples: si estás gastando $500K+ anuales en comisiones OTA, una inversión de sitio web de $100K que desplaza el 40% de esas reservas se paga en menos de cinco meses.

Preguntas Frecuentes

¿Cuánto tiempo toma ver resultados de una reconstrucción de sitio web de reservas directas? La mayoría de hoteles ven mejoras de conversión medibles dentro de los primeros 30 días de lanzar un sitio optimizado para rendimiento. El cambio de mezcla de canal -- movier realmente reservas de OTAs a directo -- típicamente toma 6-12 meses porque requiere impulso SEO, construcción de lista de correo, y cambio de comportamiento del huésped. Planifica 12-18 meses para alcanzar el objetivo de cambio del 40%.

¿Puedo mantener mi PMS existente y motor de reservas con un sitio web headless? Usualmente, sí. El punto entero de la arquitectura headless es que tu frontend está desacoplado de tus sistemas backend. Mientras que tu motor de reservas y PMS ofrecen acceso API, pueden integrarse con un frontend moderno. Dicho esto, si tu motor de reservas solo soporta integración basada en redireccionamiento, estarás limitado en cómo de profundamente puedes incrustar el flujo de reserva.

¿Cuánto cuesta construir un sitio web de hotel headless? Para un hotel independiente, un sitio bien construido headless con integración de API del motor de reservas corre $40,000-80,000. Para un grupo de hoteles con múltiples propiedades, componentes compartidos, y una capa de lealtad, espera $80,000-150,000. El mantenimiento mensual y hosting típicamente corre $2,000-5,000. Compara esto contra tu gasto de comisión OTA anual para entender el período de recompra. Puedes contactarnos para una estimación más específica.

¿Un sitio web más rápido realmente aumenta las reservas de hotel? Sí, y los datos son consistentes a través de estudios. La investigación específica de hospitalidad de Google muestra que cada mejora de segundo de tiempo de carga se correlaciona con hasta 10% tasas de conversión más altas. En nuestro propio trabajo de cliente, hemos visto hoteles ir de 1.8% a 4.5% tasas de conversión principalmente a través de mejoras de rendimiento y optimización del flujo de reserva -- antes de cualquier cambio de marketing.

¿Cuál es el mejor CMS para un sitio web de hotel en 2026? Para la mayoría de casos de uso de hotel, Sanity o Storyblok. Sanity excela en relaciones de contenido compleja (habitaciones, amenidades, planes de tarifas, contenido estacional) y tiene un nivel gratuito generoso. Storyblok ofrece un editor visual que los equipos de marketing aman. Contentful funciona bien para grupos de hoteles empresariales. WordPress puede funcionar en modo headless pero agrega complejidad. Desglosamos las opciones más en nuestro descripción general de desarrollo de CMS headless.

¿Los hoteles deberían dejar de usar OTAs completamente? No. Las OTAs sirven un propósito real para descubrimiento y para llenar habitaciones durante períodos de bajo demanda. El efecto de cartelera es real -- muchos huéspedes descubren tu hotel en una OTA y luego buscan en Google tu nombre para verificar la tarifa directa. El objetivo es optimizar tu mezcla de canal para que no estés sobre-dependiente de ninguna OTA única, y para que los huéspedes que ya pretenden quedarse contigo puedan reservar directamente sin fricción.

¿Cómo afecta la paridad de tarifas la estrategia de reserva directa? Las cláusulas de paridad de tarifas en contratos OTA históricamente previnieron hoteles de ofrecer tarifas públicas más bajas en sus propios sitios web. Sin embargo, la aplicación varía y las regulaciones están aflojando -- particularmente en la UE. El workaround arquitectónico es precios solo para miembros (grupos de usuario cerrados), empaquetado de valor agregado a la misma tarifa, y tarifas del programa de lealtad. Tu arquitectura de sitio web necesita soportar visualización de tarifa autenticada y empaquetado dinámico para hacer esto efectivamente.

¿Es Next.js o Astro mejor para sitios web de hotel? Ambos son opciones excelentes. Next.js es mejor cuando necesitas interactividad pesada -- comprobación de disponibilidad en tiempo real, flujos de reserva complejos, motores de personalización, y portales de miembros. Astro es mejor para sitios de hotel intensivos en contenido donde el rendimiento es primordial y la interacción de reserva es manejada por un widget incrustado en lugar de un flujo completamente personalizado. Para la mayoría de hoteles persiguiendo integración profunda del motor de reservas, Next.js se adelanta ligeramente. Para hoteles boutique priorizando contenido y velocidad, Astro es difícil de vencer.