The Need For Speed

Een website moet tegenwoordig responsive, leesbaar, zoekmachinevriendelijk, snel ladend en veilig zijn. Sinds ik gestopt ben met mijn Online Marketing bedrijf besteed ik veel tijd aan het lezen over best practices en ik breng ze waar mogelijk ook meteen in de praktijk.

Over een paar zaken ben ik inmiddels best tevreden, waaronder de snelheid van de websites. Het traagste onderdeel van mijn websites zijn de Google Adsense advertenties (die ik helaas niet kan verwijderen zonder failliet te gaan).

Een aantal dingen die ik heb opgepakt toen ik vorig jaar de website TractorFan, Prikkebord, Nieuwsgrazer en Boeren.nu opnieuw heb ingericht:

  • Om het inloggen veiliger te maken is de website overgezet naar HTTPS. Dit is een vertragende factor die enigszins gemitigeerd wordt door ook over te stappen naar HTTP/2 met ALPN.
  • De backend werkt met PHP7, dit levert een flink snelheidswinst op t.o.v. PHP5.xx
  • De pagina’s op de websites laden alleen scripts en stylesheets in die van toepassing zijn op die pagina’s.
  • Alle scripts en stylesheets worden samengevoegd tot 1 bestand en scripts worden geladen aan het eind van de pagina.
  • Afbeeldingen worden geladen vanaf een CDN. Enerzijds om de afbeeldingenserver te onlasten en anderzijds vanwege het voordeel dat de CDN deze afbeeldingen ook beschikbaar maken op POP locaties in het buitenland, zodat mijn buitenlandse bezoekers daar ook van profiteren.
  • In de <head> staat een deel van de CSS, waaronder de achtergrondkleur. Zo ziet de gebruiker al snel iets ‘gebeuren’ op het scherm. Dit draagt vooral bij aan de ‘ervaren’ snelheid, niet aan de reële snelheid.
  • Uiteraard wordt alle inhoud gecomprimeerd en alle static resources gecached.

Nu Google onlangs testmysite.withgoogle.com heeft gelanceerd wordt mooi inzichtelijk hoe de website zich verhoudt tot de concurrentie:

Screenshot at jul. 13 20-49-51

Nu hopen dat Google hier veel gewicht aan geeft in de organische ranking van mijn websites.

Screenshot at jul. 13 20-52-30

Waarom websites zo vaak traag zijn

Ik ben er zelf één, dus ik mag het zeggen: developers zijn over het algemeen luie mensen. Of misschien is lui niet helemaal het goede woord. Developers kiezen vaak shortcuts om snel resultaat te halen.

Een van de dingen waaraan je dat kunt zien is het internet. Een eenvoudige website, met een simpele HTML pagina kan in principe binnen een fractie van een seconde op je scherm staan. Waarom zijn er dan toch zoveel trage websites? Hier de top 5 van de meest gehoorde excuses:

“Is dat echt zo belangrijk dan?”

Ja. 40% van het bezoek haakt af als een pagina niet binnen 3 seconden op het scherm staat. In veel branches betaal je inmiddels 2 euro per Adwords klik. Ooit uitgerekend hoeveel dat kost? En hoeveel pagina’s moet men ‘door’ om tot een conversie te komen? 5? Hoeveel mensen doen dat?

Zolang er een cultuur bestaat waarbij deze zaken niet bovenaan de agenda staan is de kans groot dat er aan de performance van de site niet veel veranderd.

“Volgens mij is het snel genoeg”

Als je mij soms hoort tieren op mijn internetverbinding dan zou je het niet zeggen, maar er zitten echt voordelen aan het werken vanaf het platteland via een armetierig ADSL lijntje. Met 4 Mbit/s loop je snel tegen de pijnpunten aan die de developers met een 500 Mbit/s glasvezel verbinding werken niet meer opmerken. Ze werken met de snelste computers, via de snelste lijnen, met de nieuwste browsers.

“Het werkt toch?”

Developers worden betaald om functionaliteit te ontwikkelen. Daar worden ze op beoordeeld. Als hun functionaliteit door de acceptatietest komt, dan is er niemand die zich afvraagt hoe het nog beter kan. Misschien dat een UX designer een keer sputtert over de laadtijd, maar dan is het vaak al te laat.

Zo ontstaat er steeds meer rotzooi in de code. Tot er een punt komt waarop niemand meer weet welke code er nog gebruikt wordt en je 3 Mb aan overbodige Javascript meestuurt bij elke pagina die men op je website bekijkt. 3 Mb aan javascript verwerken op een budget mobieltje duurt vaak alleen al 3 seconden.

“Ik ben door mijn uren heen”

Budget is een andere reden. De meeste websites hebben, zodra het eenmaal werkt als afgesproken, geen budget om (bijvoorbeeld) het project te doorlopen en bottlenecks weg te nemen, overbodige code te verwijderen en de website te testen op een budget telefoon via een 3G netwerk.

Laat staan dat iemand er aan toe komt om de rotzooi op te ruimen die hierboven ontstaan is.

“HTTP/2? Wat is dan dan?”

Wat ook gewoon vaak voorkomt is een gebrek aan kennis. Hoeveel web developers en online marketeers weten van de begrippen HTTP/2, ALPN, GZIP, CDN, TTFB, Critical Path CSS en legio andere termen die er bij komen kijken om een complexe website sneller te maken? Een groot deel van de web developers is al blij dat ze de website responsive kunnen maken, want dan doet ie het toch op mobiel?

Het zou goed zijn als developers de tijd krijgen om deze ontwikkelingen bij te houden.