Traag per ongeluk vs traag door ontwerp

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.

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

3. Scripts van derden

4. Achtergrondafbeeldingen

5. Grote stylesheets

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

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.