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:

• 53% van de gebruikers overweegt een website te verlaten als die niet binnen drie seconden geladen is. (Onderzoek door Google)
• De supermarktgigant Walmart ziet zijn inkomsten 1% stijgen met elke keer de website 0,1 seconde sneller laadt.

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.

Wat is ‘rendering’?

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.

Een website is als een huis

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:

• Eerst wordt er een stevige structuur neergezet die de afmetingen aangeeft en de hele constructie recht houdt. Dat is wat HTML is voor een website: het is de constructie die structuur geeft aan het geheel: de volgorde van elementen, waar er video’s en afbeeldingen komen en hoe de website grofweg opgedeeld is.

• Daarna komt de afwerking van die structuur: We kiezen mooie ramen en deuren, verven de muren in onze lievelingskleur en werken het dak af. In websites doen we dat met CSS. CSS is de manier waarop we opmaak toevoegen aan een website door elementen gebouwd in HTML een bepaalde kleur, grootte of vorm te geven.

• Als laatste zorgen we ervoor dat alles in het huis functioneert. Als je op de knop duwt, moet het licht aan gaan. Als je de kraan opendraait, komt er water uit. Dat doen we op een website door Javascript te gebruiken. Javascript is een scriptingtaal die extra functionaliteit kan toevoegen aan je website. Animaties zijn hiervan het meest gekende voorbeeld, maar Javascript kan bijvoorbeeld ook berekeningen uitvoeren, navigatie regelen en extra inhoud laden.
  We kunnen ook websites bouwen die alleen HTML en CSS gebruiken (en dat werd 10 jaar geleden ook veel gedaan), maar da’s een beetje zoals in een huis zonder elektriciteit wonen: de deuren zullen nog steeds open gaan, maar licht? TV kijken? Telefoon? Vergeet het maar!

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.

Wat maakt een website traag (of snel)?

Er zijn een aantal zaken die we in beschouwing moeten nemen wanneer we een website snel willen maken:

• Het aantal aanvragen die we bij een server doen: elke keer we data vragen en moeten wachten op een antwoord verliezen we tijd.

• De grootte van de bestanden die over het netwerk gezonden worden: hoe meer data we verzenden, hoe langer de laadtijd.

• Het werk dat nog in de browser uitgevoerd moet worden: wanneer we gebruik maken van Javascript, moet de browser ook dat nog interpreteren én uitvoeren. Ook dat kost tijd.

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:

• TTFB (Time To First Byte): “Tijd tot de eerste byte” of de tijd tussen het starten van de aanvraag voor een webpagina (het moment waarop op een link geklikt wordt) en het tijdstip waarop je computer de eerste byte ontvangt.

• FP (First Paint): ‘Paint’ wil hier zeggen ‘iets op het scherm tekenen’. First Paint is het tijdstip waarop de eerste zichtbare pixel op je scherm verschijnt.

• FCP (First Contentful Paint): “Eerste tekening met inhoud” of het tijdstip waarop de inhoud van een website zichtbaar wordt voor de bezoeker.

• TTI (Time To Interactive): Het tijdstip waarop interactie met de website voor het eerst mogelijk is.

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/)

Welke manieren van renderen zijn er?

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:

• Server Side Rendering
• Client Side rendering

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

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:

• Het opbouwen kan veel tijd in beslag nemen, afhankelijk van hoeveel data er op de pagina moet verschijnen en de hoeveelheid HTML die dan nog gegenereerd moet worden (dat kan voor een deel opgelost worden met static rendering, zie verder). Dit zorgt voor een grotere TTFB: de pagina zal gedurende de tijd die de server nodig heeft om de pagina op te bouwen leeg blijven, om dan ineens alles te tonen.

• Deze oplossing schaalt slecht voor ‘zware’ websites. Telkens een aanvraag voor een pagina binnenkomt, moet de server wat werk uitvoeren om die op te bouwen. Een server kan zo’n heel aantal aanvragen gelijktijdig aan (afhankelijk van aanwezige CPU en RAM), maar daar zit natuurlijk een limiet aan. En wanneer die limiet bereikt wordt, zullen bezoekers moeten wachten tot een andere aanvraag afgewerkt is voor de server met hun aanvraag kan beginnen, wat tot hoge wachttijden kan leiden. De enige manier om dan verder te schalen, is om servercapaciteit bij te kopen, wat een zeer kostelijke operatie kan zijn.
  

Client side rendering

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:

• Er kan sneller ‘iets’ (de spinner bv) op het scherm getoond worden, zodat de gebruiker geen paar seconden naar een leeg scherm kijkt.

• We kunnen enkel de zichtbare delen van een webpagina renderen, zonder alle code al te moeten uitvoeren.

• Eens de app geladen is, zullen laadtijden zo goed als verdwijnen. De app ‘draait’ nu in de browser en moet alleen de stukken die veranderen opnieuw renderen.

• Zelfs navigatie (het veranderen van pagina) gebeurt nu op de client, waardoor we niet elke keer op een antwoord van de server moeten wachten om een nieuwe pagina te kunnen weergeven.

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

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.

Welke manier van rendering moet ik gebruiken?

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:

• Informatieve website van je bedrijf:
  Voor een moderne website met informatie over wat jij of je bedrijf zoal doet kan je veilig voor Server Side Rendering kiezen. Voor een relatief klein aantal bezoekers (enkele honderden per dag) zal een Server Side Rendered website niet snel in de problemen komen en je bezoekers binnen een zeer aanvaardbare tijd je inhoud voorschotelen. Voor dit soort projecten gebruiken we bij PandaPanda een standaard webserver met bijvoorbeeld WordPress of Craft CMS, zodat je ook de mogelijkheid hebt om de inhoud van je website zelf aan te passen.

• Een webapp voor intern gebruik:
  Als je een web app nodig hebt die je interne processen automatiseert of je werking stroomlijnt, dan is de kans groot dat het aantal gebruikers van die app eerder beperkt zal zijn en zal je verkoop er ook niet onder lijden als de app een seconde langer initiële laadtijd nodig heeft, omdat je klanten er niet mee in aanraking komen. In dit geval kan je kiezen voor een Client Side Rendered web app, zodat je kan besparen op de totale kost van ontwikkeling doordat developers snel en efficient kunnen werken in een framework dat ze door en door kennen. Na de eerste laadtijd zullen de gebruikers de app ook sneller kunnen gebruiken dan een SSR-app. Voor dit soort applicaties hebben we experts in huis die fantastische web apps bouwen in React.js. (Voor de opmerkzame lezer die zich nu afvraagt of we dan in React.js geen apps kunnen bouwen die op de server gerenderd worden: jawel, dat kan met bijvoorbeeld Next.js, maar die uitleg zou ons te ver leiden).

• Een klantgerichte web app
  Heb je een web app waarmee je klanten interactie aangaan? Dan is naast gebruiksgemak ook snelheid van vitaal belang en kan je gaan voor een combinatie van SSR, CSR en Static Rendering. Voor dit soort gespecialiseerde toepassingen is denkwerk en expertise nodig om tot een optimale combinatie van technieken te komen voor je specifieke noden.
  Hierbij kunnen de experts (zowel qua design, UX & UI als development) van PandaPanda je natuurlijk op weg helpen!
  

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!