Week 12 - Laadtijden
Niets is vervelender dan een website waar je minuten op moet wachten eer alles geladen is. Daarom heb ik deze week gewerkt aan het optimaliseren van de laadtijden van de webpagina’s. In mijn project zijn er twee oorzaken die de laadtijden beïnvloeden. Ten eerste vraagt het communiceren met andere websites, meer informatie hierover in blog “week 6 – social networks”, heel veel tijd. Hier spreken we niet over milliseconden maar soms zelfs over enkele seconden. Een logisch gevolg van het implementeren van meerdere sociale netwerken is hoe meer implementaties, hoe langer de laadtijden worden. De oplossing hiervoor is natuurlijk het beperken van de communicatie. Hoe doen we dat? Neen, niet door geen gebruik te maken van externe websites, maar wel door de data die we verkrijgen te ‘cachen’. Caching is een methode waarbij de opgevraagde data wordt bewaard op onze server. Hierdoor is er geen verbinding meer nodig met de externe website. Maar we moeten er wel voor zorgen dat de data die we gebruiken niet veroudert. Daarom wordt er na x aantal tijd toch opnieuw verbinding gemaakt met de externe website. De tijd dat de data bewaard wordt, is afhankelijk van de toepassing. Bijvoorbeeld: we tonen de weersverwachtingen voor vandaag en de volgende dagen. Omdat de weersverwachtingen maar af en toe wijzigen, kunnen we deze toepassing voor een relatief lange tijd gaan cachen. Maar als we bijvoorbeeld het aantal fans van onze Facebook-pagina gaan ophalen via Facebook en we hebben een populaire Facebook-pagina, dan zou het aantal fans in ideale omstandigheden wel om de paar seconden kunnen wijzigen. Bij dit voorbeeld kunnen we ons dan afvragen of cachen wel nodig is en indien we cachen, na hoeveel tijd we de data dan moeten vernieuwen. Als we niet cachen, hebben we op elk moment het juiste aantal fans maar laadt de pagina een halve seconde trager. Indien we wel cachen, is onze pagina een halve seconde sneller geladen, maar dan is het aantal fans niet altijd up-to-date.
De tweede oorzaak, waarvan de laadtijden minder groot zijn maar toch niet onbelangrijk, is de laadtijd van de queries. Vooral door gebruik te maken van subqueries kan de laadtijd aanzienlijk stijgen. Daarom heeft een collega van me, Tom Claus, me aangeraden om waar mogelijk gebruik te maken van ‘left joins’. Voor queries waar veel tabellen met elkaar gelinkt zijn, zal de laadtijd aanzienlijk dalen bij het gebruik van left joins in vergelijking met subquries. Verder is het ook nuttig om indexen te leggen op de velden die vaak worden aangesproken door queries of waar vaak op gesorteerd wordt.
Voorlaatste week
Volgende week zal het design in een paar nieuwe pagina’s kunnen geïmplementeerd worden. Het is dan trouwens mijn voorlaatste week bij Inventis! Wat vliegt de tijd voorbij zeg.
Caching en performance is een heel interessant onderwerp en vooral uitdagend, het verplicht je om kritisch naar je eigen code te kijken en de bottlenecks er uit te halen want vaak is er geen alternatieve manier om de site te versnellen buiten “foetelen” met caching.
Caching is op dat gebied de beste keuze maar toch moet je voozichtig zijn dat je niet te vaak met stale (verouderde, niet meer relavant) data zit op de website. Voor het aantal facebook fans op te halen is dit niet van groot belang, als je die cache een uur laat staan is al vaak meer dan voldoende, het aantal fans is niet belangrijk voor het functioneren van de site. Met andere data is dat dan weer wel het geval dus moet je bij het cachen keuzes maken.
Goed nadenken en plannen is dus van groot belang bij caching!
zoals je zelf al aangeeft maakt het dus niet uit.@Aaron: over de onolad handler, bekende techniek die ik vaak . Maar voor het overzicht en de simpelheid heb ik voor het artikel gekozen voor deze versie. Een handige webbouwer is slim genoeg om dit unobtrusive te maken.Verder eens met je 2de punt. Je zou het ook nog uit kunnen breiden met de DOMContentLoaded/onreadystatechange functionaliteiten. Dan meet je wanneer de pagina opbouw ingeladen en verwerkt is, en niet pas als ook de plaatjes binnen zijn.Het mooiste is misschien nog wel om al deze tijden te meten.