Een productbeschrijving is voor iedereen gelijk, maar het getoonde bezorgadres kan per ingelogde bezoeker verschillen. Moet een trage adresopvraag ook de beschrijving laten wachten? Met een denkbeeldige boekenwinkel bekijken we de keuze om algemene inhoud en persoonlijke gebieden te scheiden. Het gaat om Astro Server Islands; die hebben een andere rol dan Client Islands die knoppen in de browser interactief maken.
1. Het eerste document en latere gebieden onderscheiden
De officiële Astro-documentatie over Server Islands legt uit hoe serverrendering van een component wordt uitgesteld en via een apart verzoek terugkomt. Het eerste HTML bevat kerninhoud en wachtinformatie; de afzonderlijke reactie vervangt het gebied. Daarvoor is een adapter nodig die serververzoeken afhandelt.
Laat titel, auteur en beschrijving in het gezamenlijke document staan en kies alleen het adresoverzicht als kandidaat. Bezoekers kunnen over het boek lezen tijdens het wachten. Is het totaalbedrag nodig om de betaalknop te begrijpen, ontwerp dan ook de samenhang tussen prijs en betalen. Zichtbare onderdelen in kleine vakjes knippen voltooit de functionele scheiding niet.
Het succes hangt af van wat eerst verschijnt. Blijft de hoofdinhoud bijna leeg en wordt vrijwel alles uitgesteld, dan wachten bezoekers op meerdere laadindicatoren. Maak eerst lijsten van vragen die het eerste scherm moet beantwoorden en informatie die later mag komen. Server Islands verplaatsen het wachten; ze versnellen de databaseopvraag zelf niet automatisch.
2. De fallback als deel van het volledige scherm ontwerpen
Dit kleine voorbeeld toont de gebruiksvorm. UserDelivery en de adapter worden verondersteld afzonderlijk geïmplementeerd te zijn.
---
import UserDelivery from '../components/UserDelivery.astro';
---
<UserDelivery server:defer>
<p slot="fallback">Het bezorgadres wordt gecontroleerd.</p>
</UserDelivery>Een fallback is geen voorbijgaande versiering maar echte begininhoud. Reserveer ongeveer de uiteindelijke kaartgrootte en leg uit waarop wordt gewacht. Zonder gegevens alvast ‘Bezorging mogelijk’ tonen kan botsen met de werkelijke reactie. Maak onbekende toestand en bevestigd resultaat ook visueel onderscheidbaar.
Voor een niet-ingelogde bezoeker kan ‘Log in om je opgeslagen bezorgadres te bekijken’ nodig zijn. Trage verbinding en niet ingelogd zijn verschillende toestanden. Aparte teksten en navigatieroutes verkleinen de kans dat voorlopige ontwikkelteksten in productie blijven staan.
3. Datagrenzen klein houden
Geef alleen waarden door die voor tonen en opvragen nodig zijn. Een volledige bestelgeschiedenis doorgeven om één naam te tonen biedt eerst ruimte om afhankelijkheden te verkleinen. Sommige waarden mogen openbaar zijn, andere mogen pas na authenticatie worden opgevraagd. Controleer overdrachtsroute en zichtbare reikwijdte in dezelfde lijst.
Een Server Island-verzoek draait in een aparte uitvoeringscontext. Heeft de logica het huidige pagina-adres nodig, overweeg dan het vereiste pad expliciet vanaf de oorspronkelijke pagina mee te geven. De interne verzoek-URL gelijkstellen aan de productpagina kan verkeerde aanbevelingen of teruglinks opleveren. Controleer het echte verzoekadres in ontwikkelaarstools.
Neem een fictief geval met boeknummer en gebruikersidentificatie. Het boeknummer dient gedeelde aanbevelingen; de server behandelt gebruikersgegevens volgens authenticatie. Ook versleutelde overdracht vervangt geen autorisatiecontrole op de server. Documenteer afzonderlijk waar invoer binnenkomt en waar de uiteindelijke toegang wordt toegestaan.
4. Cache afstemmen op de doelgroep
Een algemene boekbeschrijving en persoonlijk adres kunnen moeilijk hetzelfde cachebeleid krijgen. MDN over HTTP-caching onderscheidt gedeelde en privé-caches. Bepaal eerst aan wie een reactie getoond mag worden, niet alleen of de gegevens gelijk zijn.
Open dezelfde pagina met twee testaccounts en controleer dat het adres van het eerste niet bij het tweede verschijnt. Test ook teruggaan en vernieuwen na uitloggen. Deze controle beoordeelt het samenspel van cacheserver, browser en applicatie-authenticatie. Alleen het componentbestand lezen bewijst geen veiligheid.
Ook gedeelde boekaanbevelingen hebben een updatepad nodig. Mag verouderde inhoud kort blijven staan of moet een beheerderswijziging direct worden toegepast? Noteer doel, opslagplek, toegestane veroudering en invalidatievoorwaarden in plaats van alleen ‘cache aanzetten’, zodat andere ontwikkelaars het ontwerp kunnen beoordelen.
5. Eerst trage verbindingen en fouten testen
Beoordeel de pagina niet op één normale opening. Vertraag het adresverzoek, laat het mislukken en verander de aanmeldstatus; bekijk elk scherm. Controleer leesbare hoofdinhoud, laadgebieden die volgende knoppen wegduwen en bediening die van mislukte informatie afhangt.
| Testsituatie | Wat de bezoeker moet begrijpen |
|---|---|
| Trage adresopvraag | Waarop wachten we en kan andere inhoud worden gelezen? |
| Niet geauthenticeerd | Zijn aanmeldadvies en algemene beschrijving zichtbaar? |
| Opvraag mislukt | Is er een herstelroute in plaats van een leeg scherm? |
| Accountwissel | Blijft informatie van de vorige gebruiker achter? |
Wachten meerdere Islands op elkaars resultaten, heroverweeg dan de scheiding. Eerst adres, dan verzendkosten en vervolgens betaalinformatie kan opeenvolgende wachttijden creëren. Samenhangende gegevens in één servertaak of pas op verzoek van de gebruiker ophalen kan beter zijn. Meer opgesplitste delen betekenen niet vanzelf een goede architectuur.
6. Voor en na onder dezelfde omstandigheden vergelijken
Noteer afzonderlijk eerste hoofdinhoud, volledig adres, bedienbaarheid en fouttoestanden. Een sneller begindocument kan met een sterk verschuivende adreskaart of later betalen een anders veranderde ervaring geven. Leg naast het gemiddelde vast waarop in trage gevallen werd gewacht.
Concrete selectievragen helpen: ‘Kan de boekbeschrijving al worden gelezen als deze informatie vertraagt?’ ondersteunt de keuze beter dan ‘Is de site statisch?’. Controleer de omgeving met Astro over rendering op aanvraag en begin met één klein persoonlijk gebied, inclusief echte foutgevallen.