Make use of LIMIT and browser cache

[coret]

I've made the https://makemyflix.netwerkdigitaalerfgoed.nl/goudse-straten-in-de-kijker flix, but am not too impressed with the performance. Loading time is nearly 36 seconds - for 2020 requests!? - and clicking around feels slugish.

A screenshot of the network pane also shows another issue: not all resources are being cached by the browser

Why so many requests? Can't lazy loading be applied to the images?

In the SPARQL query there are LIMITs, are these used?

[aabelmann]

@coret Ik denk dat het verstandig is om iets meer inzicht te geven in hoe de applicatie werkt voor ik dit beantwoord.

De hele applicatie gaat uit van 2 queries om alle data mee op te halen.

1. Om categorieën op te halen
2. Om items per pagina op te halen

Wanneer je op de landingspagina van een flix komt, gebeurt het volgende:

• Haalt alle categorieën op
• Haalt per categorie de eerste pagina van items op

Grappig genoeg is de reden waarom we dit zo doen, het beperken van het aantal requests.
De categorieën ophalen is nodig voor zowel de carrousel als de lijst van categorieën met de eerste 10 items.
In plaats van het ophalen van 10 items, halen we de hele eerste pagina op zodat we op de categorie pagina geen extra request meer hoeven te doen. Daarnaast bied het ons met de detail informatie om direct van de landingspagina naar de detail pagina te gaan.

Hopelijk is dit duidelijk, zo niet stel gerust meer vragen.
Maar hierdoor snap je waarschijnlijk wel al waar deze issues vandaan komen.
De Flix waar je het over hebt heeft 186 categorieën, dat betekend dat het volgende gebeurd:

1. Haal alle Categorieën op (1 request)
2. Haal eerste pagina per categorie op (186 requests)
3. Haal eerste 10 plaatjes van elke categorie op (1860 requests)

De reden dat er zoveel requests zijn komt puur door het aantal categorieën.

De opmerking maak gebruik van browser cache is beetje dubbel, in jouw plaatje zie je zelf ook dat er al (disk cache) vermeldingen zijn voor de images. De reden dat hierbij nog een default.webp opgevraagd wordt heeft te maken met de Fallback IIIF.

Uit eindelijk is het de bedoeling dat een instantie zelf een IIIF aanbied, wanneer dat het geval is, kunnen we de fallback uitzetten en is het aantal requests lager omdat we direct naar de source gaan. Op dit moment moeten we aan de server vragen of er al een cached item is en worden we ge-redirect naar de correcte url.

Hopelijk geeft dit wat duidelijkheid over wat er allemaal gebeurd, daarentegen wil ik niet ontkennen dat er een issue is.
Zoals ik ook in issue #9 zei: Dit is een goede case om te zien wat er allemaal breekt.
We zijn tot op heden altijd uit gegaan van kleine sets, minder categorieën en ik denk dat we hier een duidelijke discussie over moeten hebben, zowel qua vormgeving als functionaliteit.