Elke website is uniek en elke site heeft zijn eigen performance-issues en potentiële antwoorden daarop. De eisen van de business zoals meer features en advertenties, het aantal analyse-instrumenten, time-to-market ('gisteren klaar'), personeel en budget moeten allemaal nauwkeurig worden uitgebalanceerd om ervoor te zorgen dat de website een prettige ervaring voor de bezoeker is.
Om positief te scoren bij gebruikers en de zakelijke doelstellingen te kunnen realiseren moeten websites aan bepaalde voorwaarden voldoen. Eén belangrijke voorwaarde is het snel laden van de site. Daarvoor zijn een aantal simpele basis instellingen al voldoende. Ik laat hier enkel de revu passeren. Ik geef hier enkele aanbevelingen die een prima ‘ruturn on investemnt (roi) opleveren als we de verbeterde bezoekerservaring afzetten tegen de beperkte moeite (!) en het risico van implementatie.
1. Grote afbeeldingen Voor veel apparaten, vooral die met kleinere schermen, moeten de gedownloade afbeeldingen sterk in omvang verminderd kunnen worden zonder dat de kwaliteit daar zichtbaar onder lijdt. Om dit te bereiken moeten de afbeeldingen geschaald worden naar de resolutie en beeldschermgrootte van het betreffende apparaat. Ook helpt het om bij een initiële download alleen de afbeeldingen te laden die meteen zichtbaar zijn, en andere afbeeldingen via ‘luie’ technieken binnen te halen.
2. Lange laadtijden Als de html-code er lang over doet om de browser te bereiken, kan het front-end team weinig doen om de webapplicatie responsiever te maken. Je kan de volgende maatregelen nemen:
– Plaats de applicatie- en database-layers in de cache.
– Verdeel content in stukken en haal sommige delen op met de client via asynchroon Javascript (Ajax).
– Implementeer korte time-outs voor de content die in de back-end door de api wordt geladen om de pagina samen te stellen. Als er niet aan deze time-outs voldaan kan worden, moeten delen van de content vervangen worden met statische content-plaatshouders.
3. Niet-gecachte veel bezochte pagina’s Pagina’s worden niet gecached als ze niet tussen gebruikers gedeeld kunnen worden, als per se de laatste versie vereist is en als het verzoek het origineel moet raken vanwege tracking-doeleinden, zoals paginazichtbaarheid. Het eerste kan voorkomen worden door geen gebruikersspecifieke informatie in de html op te nemen, maar in plaats daarvan deze specifieke info op te halen via Ajax-calls of door cookies uit te lezen met JavaScript. Als de laatste versie vereist is kan door het plaatsen van een pagina in de cache, al is het maar voor enkele seconden of minuten, de gebruikerservaring sterk verbeteren en het verkeer belangrijk verminderen. Als het verzoek het origineel moet raken kan dit worden opgelost met 0 TTL of client-beaconing.
4. Content van derden en Javascript Content van derden komt van andere servers en bevat doorgaans analyse-tools, advertenties en scripts. Dergelijke content heeft de neiging de laadtijden te vertragen. HKijk ook goed naar Javascript, dat standaard het ophalen van pagina-elementen blokkeert op het moment dat het script wordt uitgevoerd.
5. Client- en edge-caching Hoewel caching een volwassen technologie is, zien we toch dat niet alle websites de mogelijkheden van caching, hetzij in de browser, hetzij op het Content Delivery Network (bijvoorbeeld de edge-server) optimaal benutten. Op dit vlak is dus vaak nog wel winst te behalen!
1 schalen van afbeeldingen geeft hoofdzakelijk problemen in de kwaliteit bij vergroten.
verkleinen kent aleen het probleem dat een te groot bestand geladen wordt.
Echter met de overhead om afbeeldingen op basis van het gebruikersscherm te schalen moet je ook
rekenen en dan afwegen wat het snelste werkt.
2 bij de meeste webapplikaties waar mysql wordt ingezet is het database ontwerp het beste
te beschrijven als suboptimaal, weinig indexes en keys waardoor de voordelen van mysql niet
tot z’n recht komen.
3
caching is altijd een goed idee echter met javascript en tracking
wordt een site weer langzamer gemaakt.
Een goed idee is om een bechmark los te laten die enkele honderden gelijktijdige
gebruikers simuleert. Daarnaast hant snelheid natuurlijk af van vele faktoren, alles
wat tussen de server en de klient staat beinvloed de snelheid.
4 beter is je afvragen of je wel kontent van derden op moet halen.
Misschien is een link toch beter.
5 er zijn heel veel sites die een webscan kunnen doorvoeren waar je netjes al dit soort
gegevens op een rijtje gepresenteerd krijgt. Die zijn wel met de nodige voorzichtigheid
te beschouwen want iedere tool stelt zijn eigen prioriteiten en beoordeelt die verschillend.
Er worden genoeg klanten een oor aangenaaid met webscans die natuurlijk altijd in het voordeeel
van de aanbieder uitvallen.
Wat ik mis is de raad om eerst te meten. Meten is weten. Dan kun je stap voor stap gaan optimeren.
Een eerste stap is je afvragen of alle eye-candy noodzakelijk is want dat kost laadtijd.
SVG kan uitkomstbieden voor grafische afbeeldingen, kleine bestanden die veel effekt kunnen hebben.
Toch, een goed artikel!
Als een pagina snel is maar nog steeds inhoudelijk onoverzichtelijk dan heb je er ook weinig aan. Dit geldt ook voor visueel gehandicapten overigens. Overmatig gebruik van animaties (flash!) en andere eyecandy. Of dat je eerst drie lagen van reclamepraat door moet om uiteindelijk aan de harde informatie te geraken. En vergeet ook niet dat ook de inhoud van belang is qua ranking van zoekmachines.
Franco, Dit zijn op zich wel juiste adviezen maar kom op zeg, zelfs een amateur webdesigner wist dit vijftien jaar geleden al.
Ik hoor je niet over, (om wat voor reden dan ook) trage of irresposive servers, overbodige javascript rommel, overmatige memory requirement (javascript) knipperende advertenties, zoektochten in overdaad aan pagina’s.
Kortom, al die dingen die niemand vraagt en nergens voor nodig zijn.
Een goede bedrijfs website is je visite kaartje en moet daarom aan een aantal heel simpele kriteria voldoen.
Je moet met minimale moeite het volgende kunnen achterhalen
– Wie ben je
– Wat doe je
– Waar kan ik je bereiken
Er zijn WAI richtlijnen voor een site met een goede usability,
niets stoort zo zeer als grijze letters op een ietsje lichtere grijze achtergrond.
Zoiets http://fonts.stajl.net/font7index.html (een voorbeeld) is niet acceptabel.
Juicy studio accessability toolbar – kan goed tonen welke kontraste te weinig zijn voor een goede leesbaarheid.
Googles zoek-algoritme schuift steeds meer naar een beoordeling van de inhoud (content), en dat is goed.
Echter bij de laatste verandering is “snelheid” een punt geworden dat zwaarder weegt.
Als je ziet hoeveel kode sommige sites moeten laden om een beetje inhoud te tonen dan verbaas je je.
Ik ben blij dat Google daar nu op let, zo wordt het koren van het kaf gescheiden.
Allen dank voor jullie nuttige feedback. Ik zal hier zeker rekening mee houden in een volgend artikel!