Netronix | Webdesign & Internet toepassingen Ronse

Google's mod_pagespeed

28 November 2010 door Michaël Rigart

Google mod_pagespeed

Google lanceerde onlangs een Apache2 module genaamd mod_pagespeed. mod_pagespeed maakt gebruik van filters waardoor websites sneller zouden weergegeven worden door internet browsers. Google beweerde zelf dat dankzij mod_pagespeed websites tot 3x sneller ingeladen worden dan normaal.

Een dergelijke claim maakte mij uiteraard nieuwsgierig. Dus liet ik mijzelf verleiden om wat meer over mod_pagespeed te gaan lezen en even te gaan uittesten.

Filters

Zoals eerder aangegeven maakt mod_pagespeed gebruik van filters. Deze filters werden ontwikkeld op basis van Google's Web performance best practices gids.

Je kan deze filters ook altijd testen op de mod_pagespeed website, of er meer over lezen op de mod_pagespeed project site.

add_instrumentation

De add_instrumentation filter heeft op zich niets te maken met optimalisatie. Deze filter staat meer in voor het rapporteren van statistieken rond de laadtijd van pagina's en het aantal requests dat nodig zijn om de pagina weer te geven.

Je kan deze filter gebruiken om na te gaan wat de eventuele oorzaken kunnen zijn van een traag ladende pagina.

extend_cache

De extend_cache filter staat in voor de caching. Het gaat per asset de nodige cache control headers gaan toevoegen maar zorgt ook voor een gehashte timestamp in de filename. Deze timestamp dient voor cache busting. De timestamp is de tijd waarop de asset voor het laatst gewijzigd is geweest. Wanneer je de asset gaat wijzigen op de server, gaat automatisch ook de timestamp (een hash in geval van mod_pagespeed) wijzigen. Hierdoor wordt het duidelijk voor de browser dat de asset gewijzigd is geweest en dat deze asset opnieuw moet gedownload worden en niet zomaar uit de browsercache opgehaald worden.

collapse_whitespace

Deze filter zorgt ervoor dat alle spaties uit je html code verwijderd worden. Dit maakt het lezen van de html code moeilijk, maar in een productieomgeving kan dit geen kwaad. Echter heb ik sterk mijn twijfels dat dit een groot voordeel zal zijn voor de performantie. Je html pagina zal wel enkele kilobytes kleiner zijn, maar op een doorsnee website zal je hier niet veel van merken. Deze filter zal volgens mij enkel nuttig zijn voor websites met heel veel bezoekers.

combine_css

De combine_css filter gaat ervoor zorgen dat meerdere css bestanden samen gebundeld worden tot 1 bestand. Hierdoor verlaag je het aantal http requests die nodig zijn voor het ophalen van bestanden. Oudere browsers hebben een limiet van 2 connecties per domein.  Moderne browsers kunnen tot 6 connecties leggen. Je kan dus zelf snel de berekening maken. Wanneer je met 6 css bestanden werkt kan je browser niets anders doen dan wachten tot hij alle bestanden gedownload heeft. Pas wanneer hij de 6 bestanden gedownload heeft, kan hij verder de rest van de site te downloaden. Herleid je de 6 bestanden naar 1 bestand, dan kan de browser ondertussen 3 tot 5 connecties openen voor het ophalen van andere resources.

combine_heads

De combine_heads filter gaat meerdere head tags binnen je html code combineren naar 1 enkele tag. Persoonlijk vind ik dit een zeer eigenaardige filter, mits ik geen enkele reden kan bedenken om gebruik te gaan maken van meerdere head tags in je html code.Je html code zal trouwens niet valid zijn wanneer je gebruik maakt van meer dan 1 head tag.

move_css_to_head

Deze filter gaat css link tags die in de html body staan, automatisch gaan verplaatsen tussen de head tag. Hoewel dit een mooi initiatief is van Google, moet ik terug melden dat deze filter voor een goede webdeveloper compleet nutteloos is, aangezien deze zelf al weet dat hij zijn css bestanden tussen de head tag moet inladen.

elide_attributes

Elide attributes zorgt ervoor dat onnodige html attributen niet verwijderd worden. Hierdoor verklein je terug de grootte van je html bestand, wat zoals eerder aangegeven maar een minimale winst aan performantie zal opleveren.

Er is ook een keerzijde aan deze filter. Wanneer je deze gaat toepassen loop je het risico om  foute html code te produceren. Ook kan het zijn dat uw code bestaat uit javascript dat gebruikt maakt van bepaalde attributen. Daarom raad ik af om deze filter te activeren.

inline_css

De inline_css filter gaat de css uit een bestand, inline toevoegen in de html code. Dit zorgt er voor dat er geen extra request moet gebeuren om het css bestand op te halen. Anderzijds zorgt het er wel voor dat je html code langer wordt. Daarom raadt Google aan dit enkel toe te passen op kleine bestanden.

Aangezien een website of een webapplicatie toch de nodige css code bevat, raad ik aan om de css code in externe bestanden te bewaren.

inline_javascript

De inline_javascript filter doet zowat hetzelfde als de inline_css filter. Deze gaat javascript code uit een bestand inline gaan plaatsen in de HTML code. Ook hier raad ik aan dit niet doen.

outline_css

De outline_css filter doet net het omgekeerde van de inline_css filter. Deze filter gaat css code uit de html opslaan in een extern bestand. Dit lijkt me een echte best practise. Dit is echter een handeling dat een goede webdeveloper reeds doet tijdens de ontwikkeling van de website of webapplicatie. Daarom is er terug geen enkele reden om deze filter te activeren.

outline_javascript

De outline_javascript filter doet net hetzelfde als de outline_css filter maar dan voor javascript. Hier terug dezelfde conclusie: pas dit toe tijdens het ontwikkelen van de website of webapplicatie.

remove_quotes

De remove_quotes filter gaat alle aanhalingstekens uit je html attributen verwijderen. Google waarschuwt dat dit een vrij “zware” operatie is voor de server en deze actie vaak het voordeel van performantie teniet doet.  Ook moet je hier opletten dat je geen foute html code laat genereren.

remove_comments

De remove comments filter gaat de commentaar uit je html code verwijderen. Soms kan het wel eens handig zijn om wat comments te hebben staan, hoewel dit niet vaak voorvalt. Ook zal de performantie winst hierdoor vrij miniem zijn.

rewrite_css

De rewrite css filter gaat je css code gaan "minifyen". Dit zorgt er voor dat alle onnodige enters en spaties verwijderd worden uit je css. Hierdoor krijg je een kleiner bestand dat sneller kan gedownload worden. Met deze filter zal je wel een verschil merken in de laadtijden. Echter zou deze filter vervangen kunnen worden door het minifyen manueel te doen.

rewrite_javascript

De rewrite javascript filter gaat ook hier hetzelfde gaan doen als de rewrite css filter maar dan voor javascript. Het gaat alle onnodige spaties en enters gaan verwijderen uit je javascript bestand. Ook hier terug hetzelfde advies. Doe dit reeds zelf tijdens de ontwikkeling en laat dit niet op de server gebeuren.

rewrite_images

De rewrite images filter kan verschillende bewerkingen uitvoeren op afbeeldingen. Het gaat bijvoorbeeld altijd de hoogte en de breedte meegeven aan je image tags. Hierdoor kan de browser de afbeelding sneller weergeven.

Buiten de afmetingen gaat de filter ook nog eens een hash toevoegen aan de bestandsnaam voor caching, of gaat hij in plaats van de afbeelding zelf te downloaden, deze gaan omzetten naar base64 code dat in de html geladen wordt. Dit zorgt wel voor de nodige risico's naar compressie zoals Google zelf aangeeft.

Conclusie

Ik heb wat gemengde gevoelens rond mod_pagespeed. Hoewel ik het een mooi initiatief vind, zie ik niet echt schokkende resultaten. Ik heb de indruk dat men de optimalisatie van websites en webapplicaties wil laten uitvoeren door de webserver, terwijl ik van mening ben dat dit allemaal zaken zijn waarmee een webdeveloper rekening moet houden. Wanneer webdevelopers er van uit gaan dat men geen rekening meer hoeft te houden met dergelijke basisoptimalisaties gaat de kunst van het webontwikkelen snel verloren gaan.

Waar ik misschien wel een voordeel zie voor mod_pagespeed is bij het gebruik van legacy projecten. Wanneer je over websites of webapplicaties beschikt waar deze richtlijnen niet op toegepast worden en de tijdsinvestering voor het manueel optimaliseren te zwaar doorwegen, dan kan het gebruik van mod_pagespeed wel een alternatieve oplossing bieden.

Toch blijf bij het standpunt dat moderne websites en webapplicaties zelf de nodige features aan boord moeten hebben die rekening houden met deze checklist. Mocht u overwegen om uw site binnenkort te vernieuwen, controleer dan zeker dat het systeem waarop men uw website wil gaan bouwen voldoet aan deze eisen!

@davelens wow, lightweight. Iets speciaal gedaan mss?