Een reviewwidget blijft oneindig laden

De cursus op https://web.dev/learn/performance behandelt onder meer het kritieke renderpad, resources die het renderen blokkeren en het laden van resources. De MDN-pagina over webperformance (https://developer.mozilla.org/en-US/docs/Web/Performance) beschrijft onder andere latency, resource timings en lazy loading, en pleit ervoor om de ervaring zo snel mogelijk beschikbaar te maken terwijl minder belangrijke delen asynchroon laden.

Wat die bronnen niet geven: een diagnose voor jouw specifieke leverancier. Welk script jouw widget gebruikt, hoe het faalt en welke reservelink acceptabel is, moet je zelf onderzoeken.

Reproduceer eerst, pas daarna iets aan.

1. Open de pagina in een privévenster met de ontwikkelaarstools en kijk in het netwerkoverzicht welke aanvragen naar het domein van de leverancier gaan.
2. Noteer per aanvraag de status: geslaagd, traag, mislukt of geblokkeerd.
3. Laat een bandbreedtebeperking of vertraging in je browsertools aan staan om een trage verbinding te benaderen. MDN raadt aan om met hoge latency te testen.
4. Blokkeer daarna handmatig het domein van de leverancier, bijvoorbeeld via de blokkeeroptie van je tools of een contentblokker, en herlaad. Blokkeer enkel dat ene domein, anders vertekent de test.
5. Kijk wat de bezoeker dan ziet: lege ruimte, een laadanimatie die nooit stopt, of een nette terugval.

Zo weet je of het probleem traagheid is, een blokkade of een fout in jullie eigen code.

Twee maatregelen werken los van elkaar.

• Vaste ruimte: geef de container van de widget een minimale hoogte en breedte op basis van wat de widget normaal inneemt. Meet die in een geladen toestand per schermbreedte. Zo verspringt de inhoud eronder niet als de widget laat verschijnt.
• Reservebronlink: plaats in of naast de container een gewone tekstlink naar de reviewpagina van de leverancier, of naar je eigen reviewoverzicht, zodat de bezoeker iets bruikbaars krijgt als het script faalt.

De reservelink moet een echte HTML-link zijn, bereikbaar met toetsenbord, en met een duidelijke linktekst. De WAI-tutorials op https://www.w3.org/WAI/tutorials/ bieden praktische richtlijnen voor toegankelijke webonderdelen. Controleer zelf welke tutorial bij jouw onderdeel past, want de bron somt geen reviewwidgets op.

De wachttijd voor de terugval bepaal je zelf op basis van je tests. De bronnen geven geen vaste waarde voor reviewwidgets.

Herhaal dezelfde proef als bij de diagnose en vergelijk.

1. Laad de pagina met normale verbinding en kijk of de widget in de gereserveerde ruimte past, op smal en breed scherm.
2. Laad met vertraging en kijk of de inhoud eronder stabiel blijft.
3. Blokkeer het leveranciersdomein en kijk of de reservelink zichtbaar is en werkt.
4. Gebruik alleen het toetsenbord: bereik je de reservelink en is de focus zichtbaar?
5. Controleer in de netwerktab of er geen extra mislukte aanvragen bijkomen.

Noteer per test wat je verwachtte en wat je zag. Dat maakt een overdracht aan een ontwikkelaar of een gesprek met de leverancier concreet.

Fictief voorbeeld, enkel als invoer: een productpagina laadt een reviewscript van een externe leverancier onderaan de beschrijving. Verwachte technische controles: netwerkstatus van de leveranciersaanvragen, de hoogte van de container in geladen en lege toestand, de zichtbaarheid van de reservelink bij geblokkeerd domein, en toetsenbordbereikbaarheid.

Geef de ontwikkelaar een notitie met vier regels: welke pagina, welk symptoom, welke aanpassing (ruimte, link, laadwijze) en welke test je opnieuw hebt uitgevoerd. Wil je zien welke publieke signalen je site toont, bekijk ze dan via Marketing Scan. Een publieke scan meet zichtbare signalen en toont niet hoe jouw widget intern faalt. Een toetsenbordcontrole van de reservelink bewijst bovendien geen volledige WCAG-conformiteit.