Elke hoteleigenaar met wie ik heb gewerkt vertoont dezelfde grimas wanneer ze het over OTA-commissies hebben. Booking.com neemt 15-18%. Expedia neemt 18-25%. Je runt een bedrijf waarin een kwart van je inkomsten verdwijnt voordat een gast zich aanmeldt. En het ergste deel? Je betaalt deze platforms om toegang tot je eigen klanten te huren.

Maar dit heb ik keer op keer zien werken, in boutique hotels en middelgrote ketens: een goed gearchitecteerde directe boekingswebsite kan 30-40% van OTA-afhankelijke inkomsten binnen 12-18 maanden naar je eigen kanaal verschuiven. Niet via trucjes. Via engineering.

Dit is geen marketingartikel over "bied gewoon een betere tarief." Dit gaat over de beslissingen op het gebied van technische architectuur -- van je boeking-engine-integratie tot je paginalaadsnelheid tot je CMS-structuur -- die directe boekingen zonder fricties maken en concurrerend met de gepolijste UX van de OTA's.

Inhoudsopgave

Hotel Direct Booking Website Architecture That Cuts OTA Commissions 40%

De werkelijke kosten van OTA-afhankelijkheid

Laten we de wiskunde doen die hotelmanagers wakker houdt.

Een hotel met 100 kamers, 75% bezetting, $180 ADR en 65% van de boekingen via OTA's:

Metriek Waarde
Jaarlijkse kamerinkomsten $4.927.500
Via OTA's gegenereerde inkomsten (65%) $3.202.875
Gemiddelde OTA-commissie (20%) $640.575
Creditcardverwerking op OTA-boekingen (3%) $96.086
Totale OTA-kosten per jaar $736.661

Dat zijn $736K die de deur uit gaan. Stel je nu voor dat je maar 40% van die OTA-boekingen naar direct verschuift. Je bespaart ongeveer $294K per jaar. Dat is geen afrondingsfout -- dat is een volledige renovatiebudget of twee extra personeelsleden.

Het Phocuswright-rapport van 2025 toont aan dat hotels met meer dan 40% directe boekingsratio 22% hogere RevPAR hebben dan hun OTA-afhankelijke concurrenten. Het gaat niet alleen om commissiebesparingen. Directe bookers verblijven langer, geven meer uit op het pand en keren vaker terug.

Waarom de meeste hotelwebsites falen bij directe boekingen

Ik heb tientallen hotelwebsites gecontroleerd en dezelfde problemen verschijnen steeds:

Ze zijn langzaam. De gemiddelde hotelwebsite laadt in 8,2 seconden op mobiel (Google-gegevens uit hospitality-benchmarks, 2024). De OTA's laden in minder dan 2 seconden. Wanneer je site vier keer langer duurt dan Booking.com, heb je al verloren.

De boekingsstroom is een omleidingssnelweghelling. Gast landt op je prachtig ontworpen homepage, klikt op "Nu boeken" en wordt gekatapulteerd naar een volledig ander domein met ander ontwerp, ander lettertype en een UI die naar 2014 schreeuwt. Vertrouwen verdampt.

Het CMS is een kooi. De meeste hotelwebsites draaien op monolithische WordPress-thema's met page builders die het onmogelijk maken om snel te itereren. Wil je een nieuwe boeking-widget plaatsing A/B-testen? Dat wordt een drie weken durende ontwikkelingscyclus.

Geen mobile-first-denken. Meer dan 70% van hotelonderzoek gebeurt op mobiel (Google Travel Insights 2025) en ongeveer 45% van directe boekingen worden nu afgerond op mobiele apparaten. Toch behandelen de meeste hotelwebsites mobiel als een nabijzaak.

Nul personalisatie. De OTA's kennen terugkerende bezoekers, tonen relevante panden, passen berichten aan op basis van zoekgeschiedenis. Je hotelwebsite toont dezelfde heldenafbeelding aan iedereen.

Dit zijn geen marketingproblemen. Dit zijn architectuurproblemen.

De architectuurstack voor directe boekingen

Dit is de stack die ik aanbeveel voor hotels die serieus zijn over directe boekingsinkomsten:

Laag Aanbevolen technologie Waarom
Frontend-framework Next.js of Astro Sub-seconde laadtijden, SSR voor SEO, ISR voor dynamische prijzen
CMS Sanity, Contentful of Storyblok Gestructureerde inhoud, meerdere talen, visueel bewerken
Boeking-engine SynXis, Profitroom of Bookassist API-first, insluitbaar, tariefbeheer
PMS-integratie Mews, Opera Cloud of Cloudbeds Real-time beschikbaarheidssynchronisatie
CDN/Hosting Vercel, Netlify of Cloudflare Pages Edge-levering, wereldwijde performance
Analytics GA4 + Looker Studio + aangepaste events Boekingskanal-attributie
Personalisatie Dynamic Yield of aangepaste middleware Herkenning van terugkerende gasten

Het kernprincipe: ontkoppel alles. Je contentbeheer, je boeking-engine, je frontend-presentatie en je property management-systeem moeten allemaal via API's communiceren maar onafhankelijk van elkaar kunnen worden bijgewerkt.

Dit is de headless-benadering die we bij Social Animal voor hospitality-klanten bouwen. Laat me door elke laag lopen.

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

Headless CMS: de basislaag

De traditionele hotelwebsite draait op een monolithisch CMS -- meestal WordPress met een thema dat inhoud, ontwerp en boeking-widgets in een rommelig geheel bundelt. Het bijwerken van het ene riskeert het andere te breken.

Een headless CMS scheidt je inhoud van je presentatie. Je marketingteam beheert kamerbeschrijvingen, fotogalerijen, speciale aanbiedingen en bloginhoud in een schone editor. Je frontend haalt die inhoud via API en rendeert deze op de manier die voor elke context logisch is -- website, mobiele app, tablet in de kamer, zelfs digitale borden.

Waarom dit speciaal voor hotels ertoe doet

Hotels hebben complexe inhoudsrelaties. Een kamertype verbindt zich met voorzieningen, tariefplannen, foto's, plattegronden, seizoenbeschrijvingen en beschikbaarheid. Een headless CMS met gestructureerde inhoudsmodellering verwerkt dit native.

In Sanity zou je het bijvoorbeeld als volgt modelleren:

// 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' }
  ]
}

Dat bookingEngineCode-veld is cruciaal -- het verbindt je CMS-inhoud met je boeking-engine's inventaris, waardoor tariefweergave mogelijk is zonder gebruikers om te leiden.

Ondersteuning voor meerdere panden

Als je een hotelketen bent, maakt headless-architectuur het mogelijk meerdere panden vanuit één CMS-exemplaar te beheren terwijl je afzonderlijke frontends voor elk pand implementeert. Gedeelde inhoud (merkstandaarden, loyaliteitsprogrammagegevens) bevindt zich op één plek. Specifieke inhoud per pand blijft scoped. Dit is aanzienlijk efficiënter dan het onderhouden van afzonderlijke WordPress-installaties.

Integratiepatronen voor boeking-engines

Dit is waar de meeste hotelwebsites conversies laten bloeden. Er zijn drie integratiepatronen en het verschil ertussen is miljoenen in inkomsten waard.

Patroon 1: Omleiding (De conversiekiller)

Gast klikt op "Nu boeken" → browser leidt om naar booking-engine-vendor.com/your-hotel → volledig ander UI, ander domein, ander vertrouwenssignaal.

Conversiepercentage: meestal 1,5-2,5%.

Dit is nog steeds hoe de meeste hotels werken en het is verschrikkelijk. Elke domeinwisseling verliest 20-30% van potentiële bookers (Baymard Institute-gegevens over afhandelingsverlating).

Patroon 2: iFrame-insluitingen (Beter, niet geweldig)

De boeking-engine rendert in een iframe op je site. Dezelfde domein in de adresbalk, maar de iframe creëert zijn eigen schuifcontext, kan je site-styling niet perfect afstemmen en breekt op mobiel vaker dan leveranciers graag toegeven.

Conversiepercentage: meestal 2,5-4%.

Patroon 3: API-first inline-integratie (Het doel)

Je frontend roept de API van de boeking-engine rechtstreeks aan. Beschikbaarheid, tarieven, kameraselectie en het boeking-formulier renderen allemaal als native componenten op je site. De gast verlaat je domein nooit. Het UI komt perfect overeen met je merk. Je controleert elke pixel van de boekingsstroom.

Conversiepercentage: meestal 4-7%.

Hier is een vereenvoudigd Next.js-voorbeeld:

// 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 voor 60 seconden
    }
  )

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

Niet elke boeking-engine ondersteunt dit niveau van API-toegang. SynXis (Sabre), Profitroom en Bookassist bieden allemaal REST-API's die diepe integratie mogelijk maken. Cloudbeds en Mews maken daar progress. Als je huidige leverancier alleen omleiding of iframe ondersteunt, is dat een serieus gesprek.

We hebben verschillende van deze API-first boeking-integraties gebouwd met Next.js en het prestatieverschil is schrikbarend.

Performance-architectuur die converteert

Google's onderzoek naar hospitality specifiek toont aan dat een verbetering van 1 seconde in mobiele laadtijd de conversies van hotelwebsites met tot 10% kan verhogen. Wanneer je concurrentie een sub-2-seconde OTA is, telt elke milliseconde.

De performance-stack

Statische generering met ISR (Incremental Static Regeneration). Je kamerpagina's, informatiepagina's, diningpagina's -- deze veranderen niet elke minuut. Genereer ze bij het compileren en valideer elke paar uur opnieuw. Resultaat: bijna onmiddellijke eerste laadbeurt.

Edge-rendered dynamische inhoud. Beschikbaarheidscontroles, tariefweergaven, gepersonaliseerde aanbiedingen -- deze moeten vers zijn. Voer ze uit op edge-functies (Vercel Edge, Cloudflare Workers) dicht bij de gebruiker.

Pipeline voor beeldoptimalisatie. Hotels zijn inhoudszwaar. Je hebt nodig:

  • WebP/AVIF-formaatverwerking op basis van browserondersteuning
  • Responsieve wijzigingsgrootte (stuur geen 4000px heldenafbeelding naar een telefoon)
  • Lui laden onder de vouw
  • Vervagen-up placeholders voor waargenomen performance

Next.js's <Image>-component verwerkt het meeste hiervan automatisch. Astro is ook een uitstekende keuze hier, vooral voor hotels die geen zware interactiviteit nodig hebben -- de zero-JS-by-default benadering levert absurde performance-scores op.

Doelmetrieken voor een hotelwebsite in 2025:

Core Web Vital Doel Waarom
LCP (Largest Contentful Paint) < 1,5s Heldenafbeelding/video moet snel laden
INP (Interaction to Next Paint) < 150ms Boeking-widget-interacties moeten onmiddellijk voelen
CLS (Cumulative Layout Shift) < 0,05 Geen springende inhoud wanneer tarieven laden
TTFB (Time to First Byte) < 200ms Edge-hosting maakt dit haalbaar

SEO-architectuur voor directe hotelboekingen

Hier is het ding over OTA-afhankelijkheid waar niemand genoeg over praat: je concurreert met OTA's voor je eigen merknaam in Google.

Zoeken naar "[Jouw hotel] boeken" en je ziet Booking.com, Expedia en TripAdvisor-advertenties boven je eigen website. Ze geven je commissiegeld uit om je potentiële directe bookers te onderscheppen.

De architectuurrespons:

Gestructureerde gegevensmarkering

Implementeer LodgingBusiness, Hotel en Offer-schema-markering op elke relevante pagina. Dit maakt rich results mogelijk -- sterrenwaarderingen, prijsreeksen, beschikbaarheidsindicatoren -- rechtstreeks in zoekresultaten.

{
  "@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"
      }
    }
  ]
}

Inhublokale architectuur

Creëer op locatie gebaseerde inhoud die reisintentie voor de gast op OTA's begint te vergelijken:

  • /things-to-do/ - Gidsen voor lokale attracties
  • /events/ - Seizoensgebonden evenementen en conferenties in de buurt
  • /neighborhoods/ - Wijkgidsen voor verschillende soorten reizigers
  • /dining/ - Restaurantaanbevelingen (inclusief je eigen eten en drinken)

Elke pagina verwijst intern naar relevante kamertypes met boekings-CTA's. Dit vangt early-stage zoekverkeer en leidt het naar directe boekingen.

Fundamentals van technische SEO

  • Programmatische hreflang-tags voor meertalige panden
  • XML-sitemap-generatie die kamertypepagina's, aanbiedingspagina's en inhoudspagina's bevat
  • Canonieke URL-beheer (kritiek wanneer u meerdere URL-patronen voor dezelfde kamer hebt)
  • Server-side rendering voor alle inhoud (SPA's met client-side rendering zijn SEO-zelfmoord voor hotels)

Tariefpariteit en prijsprikkelstrategie

Architectuur maakt strategie mogelijk, maar je hebt nog steeds een dwingende reden nodig voor gasten om direct te boeken.

Tariefpariteitsbepalingen zijn in contracten met de meeste OTA's opgenomen, hoewel regelgeving per land varieert. De EU verbiedt smalle tarievenpariteitsclausules grotendeels. In de VS is het troebeler.

Wat je altijd kunt doen:

  • Exclusieve ledentarieven: Vereisen een gratis e-mailregistratie om een lager tarief te zien. Dit is technisch een "gesloten gebruikersgroep" en schendt de meeste pariteitsafspraken niet. Je architectuur moet geverifieerde tariefweergave ondersteunen.
  • Waarde-toevoegingsverpakking: Zelfde kamertarief, maar directe bookers krijgen gratis parkeren, laat uitchecken of ontbijt. Je boeking-engine-integratie moet deze add-ons prominent weergeven.
  • Real-time prijsvergelijkingswidget: Toon je tarief naast OTA-tarieven op je eigen boekingspagina. Bedrijven zoals Triptease en The Hotels Network bieden deze widgets, maar ze werken het beste wanneer ze architecturaal zijn geïntegreerd in plaats van als scripts van derden te worden geplakt.

Loyaliteits- en personalisatielaag

De OTA's hebben massieve personalisatie-engines. Je kunt hun schaal niet evenaren, maar je kunt ze verslaan op je eigen pand's gastgegevens.

Herkenning van terugkerende gasten

Wanneer een vorige gast je website bezoekt, zou je middleware moeten:

  1. Hen herkennen (cookie of geverifieerde sessie)
  2. Hun voorkeurskamertype eerst weergeven
  3. Een gepersonaliseerd tarief tonen (loyaliteitskorting)
  4. Hun boeking details vooraf invullen
  5. Relevante upsells weergeven op basis van eerdere verblijven

Dit vereist een customer data-laag die je PMS-gastprofielen aan je website's frontend verbindt. Een eenvoudige benadering:

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

export function middleware(request) {
  const guestToken = request.cookies.get('guest_token')?.value
  
  if (guestToken) {
    // Voeg gastcontext toe aan request headers voor downstream-componenten
    const response = NextResponse.next()
    response.headers.set('x-guest-segment', 'returning')
    return response
  }
  
  return NextResponse.next()
}

Je kamerlijstcomponenten passen zich vervolgens aan op basis van deze context. Terugkerende gasten zien loyaliteitstarieven. Eerstekeer-bezoekers zien het beste beschikbare tarief met een aanbod om lid te worden van het loyaliteitsprogramma.

E-mailcapture-architectuur

Elke bezoeker die niet boekt, zou nog steeds je ecosysteem in moeten. Exit-intent overlays, prijswaarschuwingsaanmeldingen en inhoudsbeveiligde gidsen dienen allemaal dit doel. Maar de technische implementatie is belangrijk: deze moeten asynchroon laden, je kritieke renderingpad niet blokkeren en je Core Web Vitals niet ruïneren.

De verschuiving meten: KPI's die ertoe doen

Je hebt dashboards nodig die de verschuiving in kanaal-mix volgen, niet alleen algehele boekingen.

KPI Basislijn (OTA-afhankelijk) Doel (12 maanden) Doel (24 maanden)
Directe boekingsverhouding 25-35% 40-50% 50-60%
Website-conversiepercentage 1,5-2% 3,5-5% 5-7%
Mobiel conversiepercentage 0,8-1,2% 2,5-3,5% 3,5-5%
Boekings-verlatingpercentage 75-85% 55-65% 45-55%
Kostenprijs per verwerving (direct) N/A $8-15 $5-10
Kostenprijs per verwerving (OTA) $35-55 $35-55 $35-55
Website LCP (mobiel) 5-8s <2s <1,5s

Opmerking: je OTA-CPA blijft hetzelfde -- je elimineert OTA's niet, je balanceert opnieuw. OTA's blijven waardevol voor ontdekking en het vullen van noodlijdende inventaris. Het doel is ervoor te zorgen dat gasten die al weten van je hotel niet via een tussenpersoon hoeven te boeken.

Stel verbeterde ecommerce-tracking in in GA4 met aangepaste events voor elke stap van je boekingstroomkraan. Als je niet kunt meten waar mensen afhaken, kun je het niet oplossen.

De aankoop vs. bouwbeslissing

Je hebt drie paden:

  1. Sjabloonoplossingen (Bookassist, Avvio, Net Affinity) — $500-2.000/maand. Snel implementeren, beperkte aanpassingen. Goed voor onafhankelijke hotels onder 50 kamers.

  2. Aangepaste headless-build — $40.000-150.000 upfront, $2.000-5.000/maand onderhoud. Volledige controle, API-first boeking-integratie, maximale performance. Geschikt voor hotels over 50 kamers of hotelketens waarin de commissiebesparingen de investering rechtvaardigen.

  3. Hybride — Begin met een sjabloon boeking-engine maar bouw een headless frontend eromheen. Dit is vaak het gouden midden.

Als je optie 2 of 3 verkent, is dat het soort werk dat we doen. We hebben headless hotelwebsites gebouwd die sub-1-seconde laadtijden bereiken en directe boekingsratio's in het eerste jaar verdubbeld hebben.

De ROI-wiskunde is eenvoudig: als je meer dan $500K per jaar aan OTA-commissies uitgeet, een $100K website-investering die 40% van die boekingen verschuift, betaalt zichzelf in minder dan vijf maanden terug.

Veelgestelde vragen

Hoe lang duurt het voordat je resultaten ziet van een herbouw van een directe boekingswebsite? De meeste hotels zien meetbare conversieverbeteringen binnen de eerste 30 dagen na lancering van een performance-geoptimaliseerde site. De kanaal-mix verschuiving -- eigenlijk boekingen van OTA's naar direct verplaatsen -- duurt meestal 6-12 maanden omdat het SEO-momentum, e-mailijstopbouw en gedragsverandering van gasten vereist. Plan voor 12-18 maanden om dat 40%-verschuivingsdoel te bereiken.

Kan ik mijn bestaande PMS en boeking-engine houden met een headless website? Meestal wel. Het hele punt van headless-architectuur is dat je frontend is ontkoppeld van je back-end systemen. Zolang je boeking-engine en PMS API-toegang bieden, kunnen ze integreren met een modern frontend. Dat gezegd zijnde, als je boeking-engine alleen ondersteuning biedt voor op omleiding gebaseerde integratie, ben je beperkt in hoe diep je de boekingsstroom kunt insluiten.

Hoeveel kost het om een headless hotelwebsite te bouwen? Voor een onafhankelijk hotel loopt een goed gebouwde headless site met boeking-engine API-integratie tussen de $40.000-80.000. Voor een hotelgroep met meerdere panden, gedeelde componenten en een loyaliteitslaag, verwacht $80.000-150.000. Maandelijks onderhoud en hosting bedraagt meestal $2.000-5.000. Vergelijk dit met je jaarlijkse OTA-commissieuitgaven om de terugverdienperiode te begrijpen. Je kunt contact met ons opnemen voor een meer specifieke schatting.

Verhoogt een snellere website echt hotelboekingen? Ja, en de gegevens zijn consistent in onderzoeken. Google's hospitality-specifiek onderzoek toont aan dat elke seconde verbetering in laadtijd gecorreleerd is met tot 10% hogere conversiepercentages. In ons eigen cliëntwerk hebben we hotels zien gaan van 1,8% naar 4,5% conversiepercentages, voornamelijk door prestatieverbeteringen en optimalisatie van de boekingsstroom -- voordat marketingveranderingen.

Wat is het beste CMS voor een hotelwebsite in 2025? Voor de meeste hotelgebruiken Sanity of Storyblok. Sanity blinkt uit in complexe inhoudsrelaties (kamers, voorzieningen, tariefplannen, seizoenhoudige inhoud) en heeft een royale gratis laag. Storyblok biedt een visuele editor waar marketingteams van houden. Contentful werkt goed voor enterprise hotelgroepen. WordPress kan in headless mode werken, maar voegt complexiteit toe. We breken de opties meer uit in ons headless CMS development-overzicht.

Moeten hotels OTA's volledig stopzetten? Nee. OTA's dienen een echt doel voor ontdekking en voor het vullen van kamers tijdens rustige perioden. Het billboardeffect is echt -- veel gasten ontdekken je hotel op een OTA en zoeken je naam vervolgens om het directe tarief te controleren. Het doel is het optimaliseren van je kanaal-mix zodat je niet over-afhankelijk bent van één OTA en zodat gasten die al van plan zijn bij jou te verblijven direct kunnen boeken zonder fricties.

Hoe beïnvloedt tariefpariteit de directe boekingsstrategie? Tariefpariteitsclausules in OTA-contracten hebben hotels historisch gezien ervan weerhouden lagere openbare tarieven op hun eigen websites aan te bieden. De handhaving varieert echter en regelgeving wordt losser -- vooral in de EU. De architectuurworkaround is personeelsleden-exclusieve prijzen (gesloten gebruikersgroepen), waarde-toevoegingsverpakking tegen hetzelfde tarief en loyaliteitsprogrammatarieven. Je website-architectuur moet geverifieerde tariefweergave en dynamische verpakking ondersteunen om dit effectief te laten werken.

Is Next.js of Astro beter voor hotelwebsites? Beiden zijn uitstekende keuzes. Next.js is beter wanneer je zware interactiviteit nodig hebt -- real-time beschikbaarheidscontroles, complexe boekingsstromen, personalisatie-engines en ledenportals. Astro is beter voor inhoudszware hotelwebsites waar performance van het grootste belang is en de boeking-interactie wordt verwerkt door een ingebouwde widget in plaats van een volledig aangepaste stroom. Voor de meeste hotels die diepe boeking-engine-integratie nastreven, heeft Next.js een voordeel. Voor boutique hotels die inhoud en snelheid prioriteren, is Astro moeilijk te slaan.