Meer zelfs, een slechte implementatie kan je geld kosten in de meest letterlijke betekenis, zeker nu steeds meer web apps en websites bezocht worden via smartphones die – nog steeds – beperkt zijn in rekenkracht vergeleken met laptops en desktops.
Rendering is namelijk belangrijk in de snelheid waarmee je website op het scherm verschijnt en bruikbaar wordt en dat is cruciaal:
figuur 1: hoe langer de laadtijd van je website, hoe meer bezoekers hem verlaten. (bron: https://bit.ly/3d0R2Nl)
In dit artikel leggen we je uit wat rendering juist is, waar je op moet letten en waarom het belangrijk is voor je business.
Kort omschreven is rendering het proces om code (HTML, CSS en Javascript) om te zetten in een zichtbare en bruikbare website.
Wanneer web developers een website bouwen doen ze dat door gebruik te maken van HTML, CSS en (meestal) Javascript. Dat is code die de structuur, het uitzicht en de werking van je website bepaalt. Gebruik je een websitebouwer (WordPress thema’s, Wix, Weebly, …) dan bouw je jouw website veelal visueel op en doet de software voor jou in de achtergrond de conversie naar code.
Om te begrijpen wat rendering juist is moeten we bekijken wat die code nu juist doet. Daarvoor gebruik ik graag de analogie van een huis: wanneer een huis gebouwd wordt, doen we dat in stappen:
Het ‘huis’ dat een website is, wordt uit deze drie elementen opgebouwd, in code. Die code is wat over het net verstuurd wordt naar je computer wanneer je een website bezoekt.
Het ganse proces dat uitgevoerd wordt om een website op je scherm te toveren noemen we ‘rendering’. De browser ontvangt de code van een website, interpreteert die en zet die om in visuele elementen die je op je scherm ziet en waarlangs de gebruiker de interactie met de website kan aangaan.
Er zijn een aantal zaken die we in beschouwing moeten nemen wanneer we een website snel willen maken:
Voor we over de verschillende manieren van rendering kunnen praten, moeten we een paar begrippen verduidelijken die een rol spelen in de snelheid van websites:
Deze belangrijke tijdstippen komen voor in de volgorde waarin ze hier weergegeven worden en volgen elkaar – in het ideale geval – zo snel mogelijk op. Want, zoals de grafiek hieronder weergeeft, de snelheid waarmee je gebruikers de website kunnen gebruiken heeft een directe invloed op het aantal conversies!
Figuur 2: aantal conversies in verhouding tot First Page TTi(s). (bron: https://addyosmani.com/blog/usability/)
Goed, nu we wat achtergrond en begrippen over rendering kennen, kunnen we aan het echte werk beginnen! Wanneer we heel kort door de bocht gaan, kunnen we zeggen dat er twee grote ‘types’ van rendering zijn:
Het ene vindt plaats op de server (dus voor de website bij de bezoeker terecht komt) en het andere gebeurt op de client (dus op het toestel van de bezoeker). Tegenwoordig lopen de twee echter soms door elkaar heen, omdat ze elk hun eigen specifieke voor- en nadelen hebben.
Server Side Rendering is de “oude” manier van werken.Voor we Javascript begonnen gebruiken, was het namelijk ook de enige manier om pagina’s te renderen. Dit is de standaard manier waarop bijvoorbeeld WordPress je pagina’s zal ‘opdienen’ aan de bezoekers van je website. Maar ‘oud’ is in dit geval niet (noodzakelijk) gelijk aan ‘slecht’.
Wanneer een gebruiker een pagina opvraagt, doet de server het zware werk door je pagina op de server ‘samen te stellen’: de gegevens op de pagina worden uit de database gehaald (in het geval je een CMS zoals WordPress gebruikt), extra code wordt uitgevoerd en dat alles wordt op de juiste manier in tekst en HTML omgezet die dan samen naar de client gestuurd wordt.
Deze manier van werken heeft als voordeel dat, omdat de hele pagina al ‘klaar’ is voor ze bij de client terecht komt, alles tegelijk op het scherm zal verschijnen. Een server is ook sneller in het afwerken van deze taak dan onze browser. FP, FCPen TTI volgen elkaar in dit geval dus zeer snel op.
De nadelen zitten hem in het gebruik van een server om inhoud op te bouwen:
Client Side Rendering (CSR) gebeurt op de client, op het toestel van de bezoeker dus. Gemakkelijk toch, IT?
In dit geval steunt het grote deel van de implementatie (dikwijls zelfs alles) op Javascript. De webserver stuurt gewoon de hele bundel Javascript naar de client die de aanvraag doet, waarna de browser van de client overneemt. Het opgehaalde Javascript wordt door de browser geïnterpreteerd en uitgevoerd, zodat HTML gegenereerd wordt. Dit is de manier van werken die vele van de moderne frameworks voor het ontwikkelen van web apps toepassen (React.js, Vue.js, Angular.js, …).
Op deze manier bereiken we over het algemeen een snellere TTFB, omdat de server op elke aanvraag meteen met de gekende Javascript code kan antwoorden. Daarop kan ook een snelle FP volgen, zodat de gebruiker al iets op het scherm ziet verschijnen. FCP en TTI zijn voor deze manier van werken dan weer hoger en liggen verder uit elkaar, omdat het ophalen van de inhoud van de pagina nu in de browser gebeurt. Meestal krijgen gebruikers dan een spinner te zien tot alle data geladen is.
Een mogelijk nadeel van CSR is dus dat de gebruiker de eerste keer hij of zij op de webapp terecht komt even zal moeten wachten (en soms langer dan bij SSR) tot hij interacties kan maken met de app.
Daar tegenover staan wel een heel aantal voordelen:
Doordat de ganse website in Javascript gebouwd kan worden – en door de aanwezigheid van goed onderbouwde en ondersteunde frameworks (React.js werd door Facebook ontwikkeld, Angular door Google) op de markt, geeft deze manier van werken ook aan developers veel meer mogelijkheden en flexibiliteit én kunnen ze zelfs sneller werken.
Een gevaar hierbij is wel dat die frameworks out-of-the-box nogal veel Javascript code genereren en dat de developer slechte (= trage) of veel te veel Javascript code schrijft, waardoor rendering op de client onnodig veel tijd inneemt en zelfs (veel) trager wordt dan een Server Side Rendered-website. Het is dus wel noodzakelijk om developers te hebben die weten waar ze mee bezig zijn (zoals de knappe koppen bij PandaPanda 😉).
Static Rendering is een vorm van SSR, maar ook weer niet helemaal. Bij Static Rendering worden de pagina’s van een website gegenereerd op het moment dat de developer de website bouwt. Eens de website klaar is, wordt de code van de developer éénmaal gerenderd op de server en worden de pagina’s als statische pagina’s opgeslagen op de server, waarna ze op die manier aan de client aangeboden kunnen worden.
Deze manier van werken combineert de voordelen van CSR en SSR: we kunnen de tools (React.js, Angular, Vue.js) gebruiken die ons als developers de kans geven om snel te werken en prachtige apps af te leveren én we krijgen daarbij de snelle FP, FCP en TTI van een Server Side Rendered pagina (omdat de pagina al klaar is wanneer ze bij de client arriveert). Verder kan ook de TTFB laag gehouden worden omdat de pagina al klaar staat op de server en dus niet meer ‘opgebouwd’ dient te worden.
Bij PandaPanda gebruiken we Gatsby als framework (gebouwd op onze lievelings-tool: React.js) om razendsnelle statically rendered webapps af te leveren.
Echter, ook hier is er weer een nadeel te vinden, want wat als de content van je website veel verandert, of gebruikers toelaat om zelf content toe te voegen (bv een blog) of delen aan te passen? In dat geval moet de website elke keer ‘ge-rebuild’ (opnieuw opgebouwd) worden wanneer inhoud aangepast wordt en dat is niet in alle gevallen aan te raden.
We horen je al roepen: “Help! Elke oplossing heeft voor- en nadelen, welke manier moet ik nu gebruiken?!”
Goeie vraag! Zoals je hebt kunnen lezen, is rendering inderdaad een complex onderwerp en is er niet voor elke toepassing zomaar een beste manier van werken, omdat elke website of webapp zijn eigen, specifieke noden heeft. Toch kunnen we voor een aantal use-cases wel wat aanbevelingen doen:
Zo, een hele hoop informatie, maar dat kon niet anders bij het bespreken van zo’n complex onderwerp! Hopelijk kan je door deze uitgebreide verduidelijking van de verschillende render-bomen het render-bos weer zien!
Schrijf je in voor de nieuwsbrief & ontvang alle nieuwste updates.