139 gidsen van Chrome die je AI-bouwer negeert

Je opent je eigen site op je telefoon, in de trein, met twee streepjes bereik. Eerst wit. Dan het menu. En dan pas, ergens na twee tellen, de foto waar je het meest trots op bent. De browser wist niet dat juist dat beeld eerst moest komen, want niemand had het hem verteld.

Het Chrome-team heeft daar iets op bedacht. Ze hebben hun eigen adviezen over moderne HTML, CSS en browser-API’s in een doorzoekbare set gidsen gezet, speciaal voor codeeragenten: modern-web-guidance. Je bouwer zoekt erin voordat hij code schrijft. Ik heb geteld hoeveel het er zijn en daarna gekeken wat er in de praktijk van terechtkomt.

139 gidsen, veertien onderwerpen, een zoekbalk

De set telde op 6 september 2026 precies 139 gidsen. Interactiepatronen zijn met 29 stuks de grootste groep, daarna performance (24), visueel ontwerp (16), CSS (15) en formulieren (15). Elke gids staat los, zodat je agent er precies één bij pakt in plaats van een handboek in te laden.

Het werkt als een zoekmachine, niet als een boek. Je stelt een vraag in gewone taal en krijgt de vijf gidsen terug die er het dichtst bij liggen, met een score erbij. Daarna haal je alleen de gids op die je nodig hebt.

npx -y modern-web-guidance@latest search "hero image loads too late on mobile"
npx -y modern-web-guidance@latest retrieve optimize-image-priority

In de repo zitten kant-en-klare plugin-bestanden voor Claude, Cursor, Grok, Gemini en Kimi. Lovable staat er niet bij, maar als je je code exporteert naar GitHub en er lokaal een agent op zet, kun je het gewoon gebruiken.

22 van de 34 sites laten de browser zelf raden

Ik wilde weten of dit soort adviezen aankomt in wat AI-bouwers opleveren. Dus heb ik 43 live sites op lovable.app verzameld via Google en Brave, ze op 6 september in een headless Chromium geladen op 1280 bij 900 pixels, en de DOM gemeten nadat JavaScript klaar was. Bij 39 lukte dat, vier liepen in een time-out.

Wat eruit kwam:

• 34 sites hebben minstens één afbeelding boven de vouw. Twaalf daarvan zetten fetchpriority="high" op een beeld, 22 niet.
• Zeven sites zetten loading="lazy" op een afbeelding die al in beeld staat.
• Van de 752 afbeeldingen die ik tegenkwam missen er 534 een width en height.
• Drie sites gebruiken het HTML-element <details>. Twintig bouwen uitklapbare blokken na met div’s en aria-expanded.
• Geen enkele site gebruikt <dialog> of het popover-attribuut.
• Van de 37 invoervelden hebben er drie een autocomplete-waarde.

Wat dit niet bewijst: lovable.app-adressen zijn gratis preview-links. Daar staan prototypes, portfolio’s en clubavond-pagina’s tussen, geen webshops met een marketingbudget. Ik heb per site alleen de homepage bekeken. En 39 sites is een steekproef, geen sector.

Lazy loading op je hero is de dure fout

Van die zes bevindingen kost er één je meteen geld. Zet je loading="lazy" op de grootste afbeelding boven de vouw, dan wacht de browser bewust met downloaden tot hij zeker weet dat je hem nodig hebt. Precies het beeld waar Google je Largest Contentful Paint aan afmeet.

De gids is er kort over. Nooit lazy op je LCP-beeld, wel fetchpriority="high". En voor plaatjes die technisch boven de vouw staan maar onzichtbaar zijn, zoals een mega-menu of een carousel-slide die nog niet aan de beurt is, juist fetchpriority="low".

<img src="/hero.jpg" alt="..." width="1200" height="630" fetchpriority="high">
<img src="/menu-promo.jpg" alt="..." width="300" height="150" fetchpriority="low" loading="lazy">

Die width en height staan er niet voor de sier. Zonder die twee weet de browser niet hoeveel ruimte hij moet reserveren, dus springt je tekst omlaag zodra het beeld binnenkomt. Dat is je Cumulative Layout Shift, en dat is de goedkoopste Core Web Vital om te repareren: twee getallen per afbeelding.

Waarom Ctrl+F jouw eigen antwoord niet vindt

De twintig sites met een nagebouwde accordeon hebben een probleem dat je alleen merkt als je ernaar zoekt. Een dichtgeklapt paneel dat met display: none verdwijnt, bestaat voor de zoekfunctie van de browser niet. Je bezoeker drukt Ctrl+F, typt het woord dat letterlijk in jouw FAQ staat, en krijgt nul treffers.

Met <details> gebeurt dat niet. De browser klapt het paneel zelf open als je ernaar zoekt, en een link naar een tekstfragment landt op de goede plek. Wil je de vormgeving helemaal zelf doen, dan is er hidden="until-found", met het beforematch-event om je pijltjes en aria-states mee bij te werken. Een groep panelen waarvan er maar één open mag, is een name-attribuut op elke <details>. Geen JavaScript.

<details name="faq"><summary>Wat kost het?</summary><p>Vanaf ...</p></details>
<details name="faq"><summary>Hoe lang duurt het?</summary><p>Meestal ...</p></details>

Eerlijk erbij: dit is geen rankingtruc. De gids belooft vindbaarheid binnen de pagina, deep links en schermlezers die het snappen. Wie je vertelt dat <details> je posities omhoog duwt, verkoopt je iets.

Het ligt niet aan Lovable, het ligt aan wat het model ooit gelezen heeft

Er zit geen slechte generator achter deze cijfers. Er zit een taalmodel achter dat miljoenen pagina’s heeft gezien waarin een uitklapmenu een div met een klik-handler was, want zo deed iedereen het toen. fetchpriority kwam in 2022 in Chrome, de exclusieve <details>-groep eind 2023. Dat is dun in de trainingsdata en dik in de documentatie.

Daarom is een zoekbare gidsenset slimmer dan een nieuwe modelversie afwachten. Je agent hoeft het niet te weten, hij moet het kunnen opzoeken. Het is dezelfde beweging als bij de duplicaten die AI-builds produceren: het patroon zit in het gereedschap, niet in jouw prompt.

Een attribuut repareren terwijl je HTML leeg is, is dweilen

Nu het ongemakkelijke deel van mijn eigen meting. Ik verkoop technische fixes voor AI-gebouwde sites, dus het komt mij goed uit om te wijzen op 22 ontbrekende attributen. Maar in dezelfde meting zit een getal dat harder aankomt: bij 31 van de 43 sites levert de server minder dan 200 tekens leesbare tekst voordat JavaScript draait. De rest van de pagina bestaat pas nadat de browser aan het werk is gegaan.

Daar helpt geen enkel attribuut tegen. Dat is de dynamic content paradox, en de oplossing is prerenderen. Doe dat eerst. Een hero die 200 milliseconden sneller binnenkomt op een pagina die Google niet leest, is een mooiere versie van niets.

De interessantste categorie zit nog achter een vlag

Drie van de 139 gidsen gaan over WebMCP. Daarmee bied je onderdelen van je pagina aan als gereedschap voor een AI-agent die langskomt: een formulier krijgt een naam en een beschrijving, en de agent kan het invullen zonder jouw knoppen te hoeven raden. Je legt uit wat je site kán, in plaats van te hopen dat een bot het uit je HTML afleidt.

Bouw het vandaag nog niet. Het draait alleen in Chromium 146.0.7672.0 of hoger, achter de vlag #enable-webmcp-testing, het ondersteunt alleen tools en de specificatie is nog een concept van een community-groep. Wel is dit het eerste concrete voorstel dat ik zie voor de vraag waar iedereen op zit te wachten: hoe bedien je een website als je geen mens bent.

Vijf regels werk, en je bezoeker vindt zijn antwoord terug

Open je site, klap je FAQ dicht en druk op Ctrl+F. Typ een woord dat alleen in het dichtgeklapte antwoord staat. Springt de browser er niet naartoe, dan staat je antwoord achter display: none en heb je vijf regels werk om er <details> van te maken. Twee minuten, en je hoeft er geen agent voor te starten.

Wil je de rest ook nalopen, dan staat het volledige stappenplan in Lovable SEO fixen.

Komt WebMCP uit preview, dan verschuift de vraag over je site van “kan Google dit lezen” naar “kan een agent dit bedienen”. De sites die dan al schone HTML hebben, hoeven alleen een paar namen toe te voegen. De rest begint opnieuw.