Traag per ongeluk vs traag door ontwerp

Ik maak meestal onderscheid tussen traag per ongeluk en traag door ontwerp. Leer hoe dit je kan helpen de core web vitals te verbeteren

Arjen Karel - linkedin

Last update: 2024-07-13

Traag per ongeluk vs traag door ontwerp.

Wanneer je mij inhuurt om de Core Web Vitals te repareren of erover te praten, zul je me op een gegeven moment horen praten over traag per ongeluk vs traag door ontwerp. Ik denk dat het een cruciaal onderscheid is om te maken en in dit artikel zal ik uitleggen hoe dit je zal helpen de Core Web Vitals te verbeteren.

Wanneer iemand me vraagt om te adviseren en de Core Web Vitals te repareren, is er altijd iets mis. Traagheid komt altijd voort uit anti-patronen. Bijvoorbeeld een 'Lazy Loaded Largest Contentful Paint afbeelding', 'Grote, niet-geoptimaliseerde afbeeldingen', 'Sliders', 'render blocking JavaScript' enzovoort.

Het kost niet veel om een anti-patroon te introduceren. Soms is alles wat je hoeft te doen om een anti-patroon te creëren, een plugin installeren of best practices voor een korte tijd vergeten.

Nu categoriseer ik deze anti-patronen graag in 'traag per ongeluk' en 'traag door ontwerp' omdat de manier waarop ik ze repareer volledig tegengesteld is.

Traag per ongeluk

Ik hou van 'traag per ongeluk' anti-patronen. Je deed iets dat de pagina vertraagde. Je maakte een fout. Je wist niet dat er een veel snellere manier is om dit te doen. Geen zorgen, ik kan fouten herstellen.

Dus het categoriseren van deze 'fouten' is logisch. Het geeft me een lijst van gemakkelijk te repareren, high impact verbeteringen die ik naar je devteam kan sturen (of zelf kan repareren). Er is meestal heel weinig discussie nodig. Het verbeteren van deze anti-patronen is gewoon logisch vanuit alle richtingen. Zodra ze zijn opgelost, zullen de Core Web Vitals verbeteren.

Hier zijn een paar voorbeelden van anti-patronen die ik dagelijks tegenkom. Wanneer ik uitleg wat en waarom krijg ik meestal 'ohh , ik wist niet dat dit de pagina zou vertragen'.

1. Niet lazy afbeeldingen

Het meest voorkomende anti-patroon is niet-lazy afbeeldingen. Afbeeldingen die niet lazy loaded zijn, worden al in de vroege stadia van het laden van de pagina in de wachtrij geplaatst om te downloaden. Dit zal netwerk- en CPU-bronnen gebruiken. Het is niet logisch om kostbare bronnen toe te wijzen aan afbeeldingen die niet eens zichtbaar zijn, toch?

2. Lettertypen van derden

Web-fonts zijn geweldig. Ze zullen de look en feel van de pagina aanpassen en verbeteren. Helaas zal het gebruik van een derde partij provider zoals Google fonts de lettertypen niet optimaliseren voor jouw specifieke situatie.

Lettertypen van derden vereisen een extra render-blocking stylesheet, een nieuwe verbinding met een webserver (terwijl je al deze echt snelle verbinding met je origin server hebt) en zullen waarschijnlijk meer lettertypen aan de browser toevoegen dan je daadwerkelijk gebruikt.

Het zou logischer zijn om je lettertypen zelf te hosten, ze te preloaden en een aangepaste optimalisatie strategie aan elk lettertypebestand toe te wijzen. Dat is weer een snelle overwinning!

3. Scripts van derden

Hoewel er niets mis is met scripts van derden, veroorzaken ze veel problemen vanwege de manier waarop ze aan pagina's worden toegevoegd. Ik kom onbelangrijke scripts van derden tegen (zoals de facebook tracking pixels, social media knoppen, beoordelingswidgets etc) die eigenlijk de hele pagina blokkeren.

Het is relatief eenvoudig en logisch om deze scripts uit te stellen en in te plannen totdat de browser het belangrijkere werk heeft gedaan. Uiteindelijk heb ik niet echt iets kritieks aan de site veranderd, hij ziet er nog steeds hetzelfde uit en laadt veel sneller. Ik heb gewoon de volgorde veranderd waarin dingen worden gedaan.

4. Achtergrondafbeeldingen

Vanuit een Core Web Vitals perspectief zijn achtergrondafbeeldingen weinig zinvol. Achtergrondafbeeldingen kunnen niet lazy loaded worden, ze zijn niet responsief en je hebt weinig controle over hun timing en prioriteit.

Met een paar eenvoudige fixes kunnen we deze achtergrondafbeeldingen transformeren in normale afbeeldingen die we kunnen lazy loaden, responsief maken en hun prioriteit aanpassen. Dat zal zeker de Largest Contentful Paint verbeteren.

5. Grote stylesheets

Stylesheets zijn render blocking. Dat betekent dat terwijl de browser de stylesheets laadt, de pagina wit blijft. Er zijn veel dingen die je kunt doen om dit op te lossen. Bijvoorbeeld, ongebruikte stijlen verwijderen, de stylesheet opsplitsen, browser caching verbeteren of Critical CSS toevoegen.

Zodra we de stylesheets hebben verbeterd, zullen je Largest Contentful Paint en First Contenful Paint dramatisch verbeteren!

Traag door ontwerp

Traag door ontwerp is het deel waar je je zorgen over moet maken. Je hebt structurele keuzes gemaakt die de pagina vertraagden. Ze omvatten meestal UX design keuzes of JavaScript code die het zichtbare deel van de pagina zodanig wijzigt dat er geen goede workarounds zijn.

Het probleem met 'traag door ontwerp' is dat het niet onmiddellijk op te lossen is door kleine wijzigingen aan te brengen. Het vereist meer planning en het herschrijven van enkele kernfuncties van de site.

Het eerste wat ik moet doen is de intentie achterhalen: Waarom heb je dit gedaan? Wat waren de overwegingen en wat wilde je precies bereiken? En dan binnen die parameters een beter alternatief vinden!

Hier zijn enkele voorbeelden van de meest voorkomende 'traag door ontwerp' fouten.

1. Sliders

Sliders werken meestal zo: Wanneer de pagina rendert, injecteert een JavaScript de slider in de pagina. Zonder dit JavaScript ziet de pagina er compleet anders uit. Dit zal een langere Largest Contentful Paint veroorzaken, waarschijnlijk een Layout Shift en hoogstwaarschijnlijk problemen met de First Input Delay.

Er is geen snelle oplossing. Het uitstellen van de JavaScript zal de paint metrics verbeteren maar zal de slider vertragen en een layout shift veroorzaken. De slider script kritiek maken zal de Layout Shift oplossen maar zal de paint metrics vertragen.

De oplossing is om de pagina progressief te verbeteren. Zorg er eerst voor dat de slider rendert zonder JavaScript en verbeter vervolgens de pagina en transformeer de reeds aanwezige slider afbeelding in een volledige slider.

Het leuke is: 9 van de 10 keer wanneer ik dit uitleg, stelt de site-eigenaar onmiddellijk voor om de slider te verwijderen. Daarom is het belangrijk om te vragen naar de intenties en overwegingen van deze sliders. Meestal 'waren ze er gewoon'.

2. Product zoom

Product zoom werkt zo: op je gemiddelde webshop hover je over een productafbeelding en kun je inzoomen op een deel van het product. 'Product zooms' hebben meestal hetzelfde probleem als sliders. Een stukje JavaScript code neemt je afbeeldingen, verbergt ze, en herschrijft ze vervolgens naar de pagina als zoombare afbeeldingen. Dit zal een langere Largest Contentful Paint veroorzaken, waarschijnlijk een Layout Shift en hoogstwaarschijnlijk problemen met de First Input Delay.

Het verschil met de slider is dat geen enkele producteigenaar ooit zal zeggen: "oh verwijder deze functionaliteit maar". Het is belangrijk en verhoogt de conversie.

De oplossing is hetzelfde als de slider fix. Het zoom script zou de originele afbeeldingen niet moeten verbergen maar de productafbeelding functionaliteit uitbreiden. Helaas is de zoom functionaliteit meestal niet gemakkelijk op te lossen en zal wat werk vereisen om het precies goed te krijgen.

3. inline jQuery / inline JavaScript afhankelijkheden

Inline jQuery is een probleem dat begon als een 'traag per ongeluk' maar na verloop van tijd erger werd. Ongeveer 50% van de sites die ik bekijk, heeft last van dit probleem. Omdat inline scripts afhankelijk zijn van een eerder script (meestal jQuery), kun je jQuery niet meer uitstellen. Dit zal alle paint metrics vertragen.

De fix is simpel: Verplaats deze scripts gewoon naar een extern script. Nu kun je zowel jQuery als het aangepaste script uitstellen.

Waarom plaatste ik dit dan in de 'traag door ontwerp' categorie? Wanneer ik vraag naar intentie en overweging krijg ik meestal 'oh, ik weet het niet'. En dat is het echte probleem. Er is een gebrek aan kennis over hoe JavaScript werkt. Ik kan er vrij zeker van zijn dat deze fout in de toekomst herhaald zal worden. Dit betekent dat de oplossing niet hetzelfde is als de fix. Ik zal het devteam moeten opleiden over JavaScript afhankelijkheden en timing.

4. Grote (hero) afbeeldingen

Een ander traag door ontwerp probleem zijn grote afbeeldingen. Sommige sites moeten gewoon 'het publiek verbazen' met veel full size afbeeldingen. Stel je voor dat je posters verkoopt. Je zou waarschijnlijk hoge kwaliteit, grote afbeeldingen aan je bezoekers willen serveren. Deze afbeeldingen, hoe goed je ze ook optimaliseert, zullen altijd langer duren om te downloaden dan kleinere afbeeldingen.

Op dit punt (ervan uitgaande dat de afbeeldingen allemaal geoptimaliseerd zijn) is het enige dat ik kan doen kijken of er enige speelruimte is. Hebben we echt 4k afbeeldingen nodig of zou full-hd ook volstaan?

5. Interactieve kaarten

Een ander probleem dat ik vaak tegenkom zijn interactieve kaarten. Wanneer een pagina een interactieve kaart heeft, is de hele bedoeling van deze pagina om de bezoeker met de kaart te laten interageren. Het is duidelijk dat het even gaat duren voordat die kaart geladen is.

Er is geen weg omheen. We zullen wat traagheid moeten accepteren. Maar er zijn dingen die we kunnen doen. We kunnen ervoor zorgen dat de kaarten met de hoogste prioriteit worden geladen. Meestal zijn deze pagina's niet geoptimaliseerd voor vroege JavaScript-uitvoering. In dit geval was dat de verkeerde keuze. We hebben het script nodig om zo vroeg mogelijk te downloaden en uit te voeren!

6. Trage API's

Traag door ontwerp problemen die voortkomen uit trage API's zijn meestal te vinden in SPA sites zoals REACT NextJS of Angular. Trage API's zullen meestal grote Layout Shifts veroorzaken omdat componenten te laat renderen na gebruikersinteractie. Problemen zoals dit vereisen meestal een multi-team aanpak

Conclusie

Het kan nuttig zijn om onderscheid te maken tussen traag per ongeluk en traag door ontwerp als het gaat om de Core Web Vitals. Traag per ongeluk is meestal gemakkelijk op te lossen, terwijl traag door ontwerp een grondigere multidimensionale aanpak vereist.