Google geeft Apache-module voor webserveroptimalisatie vrij
Google heeft voor de veelgebruikte Apache-webserver een module vrijgegeven die het laden van webpagina's flink zou versnellen. De internetreus claimt dat met mod_pagespeed snelheidswinsten van gemiddeld 50 procent zijn te behalen.
Mod_pagespeed versnelt de Apache 2.2-webserver met behulp van filters op meer dan vijftien manieren, zo stelt Google. Een aantal daarvan zou door webmasters lastig zelf te configureren zijn. Zo optimaliseert de module pagina's die door cms'en zijn gegenereerd, zonder dat er aanpassingen in het contentmanagementsysteem nodig zouden zijn. Ook kan de module in bepaalde gevallen plaatjes opnieuw comprimeren en alleen de gewijzigde bytes naar de client versturen.
Verder is de levensduur van statische grafische elementen in de cache tot een jaar opgerekt, bijvoorbeeld voor sitelogo's, terwijl deze nog steeds probleemloos geüpdatet zouden kunnen worden. Webontwikkelaars kunnen mod_pagespeed gebruiken om de aanbevelingen van de Page Speed-extensie voor Firefox eenvoudiger in hun webservers te implementeren.
Google claimt dat uit praktijktests van Apache-configuraties die met mod_pagespeed zijn uitgerust blijkt dat de laadtijd van websites met gemiddeld 50 procent kan worden gereduceerd. De zoekgigant heeft de module beschikbaar gesteld voor CentOS, Fedora, Debian en Ubuntu, in zowel 32bit- als 64bit-versies. Google werkt ook samen met de hostingbedrijven Go Daddy en Contendo voor het implementeren van de Apache-module in hun configuraties.
Reacties (54)
Leuk, maar ik gebruik lighttpd en pound als proxy methode....
Altens kun je met pound dus load balancen naar een lighttpd en apache server, kan het altijd eens een keer testen
Edit: Oeh ik ben eerste
Altens kun je met pound dus load balancen naar een lighttpd en apache server, kan het altijd eens een keer testen
Edit: Oeh ik ben eerste
[Reactie gewijzigd door Power2All0wnzj0 op donderdag 4 november 2010 10:17]
Ik vergeef je dit keer 
tenmiste was je nog redelijk ontopic 
.
Google doet wel zijn best om het internet efficienter te maken(lees sneller).
tenmiste was je nog redelijk ontopic .Google doet wel zijn best om het internet efficienter te maken(lees sneller).
Ik vraag me af hoe zich dit verhoudt tot een geoptimaliseerde nginx. Heeft iemand daar toevallig al zinnige info over?
nginx zal nog steeds veel sneller zijn dan apache voor puur statische files. Dit zorgt alleen maar voor enkele optimalisaties die je zelf ook kan doen, alleen doet apache het nu voor je.
Ik denk dat het zelfs nadelig is voor de pure performance; je voegt namelijk gewoon een extra stap aan een request toe. Een request die deze filter niet kan optimaliseren zal dus in theorie langzamer zijn met deze filter aan, dan een gelijk geconfigde apache met filters uit.
Ik denk dat het zelfs nadelig is voor de pure performance; je voegt namelijk gewoon een extra stap aan een request toe. Een request die deze filter niet kan optimaliseren zal dus in theorie langzamer zijn met deze filter aan, dan een gelijk geconfigde apache met filters uit.
Klopt, maar die stap extra zal misschien 3ms kosten, terwijl de behaalde snelheidswinst bijvoorbeeld 5ms is (bijvoorbeeld). Dus een extra stap hoeft niet persé slecht voor de latency te zijn.
Je bedoelt dat je (bijvoorbeeld) beter zelf je javascript en css kan minifien dan dat je apache dat voor je laat doen? Zit wat in ja, maar ik neem aan dat dat soort filterslagen ook wel intern gecacht worden. Ik kan me niet voorstellen dat het dan niet per definitie sneller wordt.
Maar goed, da's een kwestie van de docs lezen, denk ik
Maar goed, da's een kwestie van de docs lezen, denk ik
Het doet een aantal optimalisaties die vrij bewerkelijk zijn om zelf goed uit te voeren. Dus in die zin kan het nuttig zijn om hier gebruik van te maken.
Het nadeel is natuurlijk dat e.e.a. weer niet specifiek voor jouw website is geschreven, waardoor sommige optimalisaties beter hadden kunnen uitpakken als je ze met de hand had uitgevoerd. De vraag is natuurlijk wel of je daar dan als developer wel de tijd voor had gekregen/genomen.
Voorts lijkt het me dat je apache met deze module prima kan combineren met bijvoorbeeld een nginx of varnish reverse proxy, waardoor je in wezen dezelfde rauwe performance bereikt, maar toch profiteert van de features van deze module.
Het nadeel is natuurlijk dat e.e.a. weer niet specifiek voor jouw website is geschreven, waardoor sommige optimalisaties beter hadden kunnen uitpakken als je ze met de hand had uitgevoerd. De vraag is natuurlijk wel of je daar dan als developer wel de tijd voor had gekregen/genomen.
Voorts lijkt het me dat je apache met deze module prima kan combineren met bijvoorbeeld een nginx of varnish reverse proxy, waardoor je in wezen dezelfde rauwe performance bereikt, maar toch profiteert van de features van deze module.
kortom eigenlijk zeg je hier dat je als hoster beter deze plugin kunt isntalleren en documenteren dat je het doet.
afhankelijk van de webhost en het pakket zou je hem vervolgens default aan of default uit zetten met de mogelijkheid om via je .htaccess (of hoe dat bestand ook heet) de functie per account / of map weer uit te zeggen. net zoals je bij sommige host op deze manier kunt kiezen tussen php4 en php5 tussen mod_rewrite of toch maar niet etc.
afhankelijk van de webhost en het pakket zou je hem vervolgens default aan of default uit zetten met de mogelijkheid om via je .htaccess (of hoe dat bestand ook heet) de functie per account / of map weer uit te zeggen. net zoals je bij sommige host op deze manier kunt kiezen tussen php4 en php5 tussen mod_rewrite of toch maar niet etc.
Wat is er langzamer aan snelheidswinsten van 50%?
de mogelijkheid dat wanneer je deze optimalisaties fine tuned (dus handmatig instelt) je geen +50 maar +80 % kunt halen.
mensen zijn altijd slimmer dan scripts en een goede webdeveloper weet dus ook met welke cashingwaarde, i/o-versneller of ander tweak juist dat project (dus niet al die andere 80) het beste en het snelste en het meest naukeurig draait. zo'n google tooltje kan alleen maar met gemiddels werken en meten, - dat kan goed gaan en fout gaan en die lijn is vrij dus, dus moet die plugin daar rekening mee houden en grotere veiligheids marges nemen dan waneer een mens het zou hebben gedaan...
mensen zijn altijd slimmer dan scripts en een goede webdeveloper weet dus ook met welke cashingwaarde, i/o-versneller of ander tweak juist dat project (dus niet al die andere 80) het beste en het snelste en het meest naukeurig draait. zo'n google tooltje kan alleen maar met gemiddels werken en meten, - dat kan goed gaan en fout gaan en die lijn is vrij dus, dus moet die plugin daar rekening mee houden en grotere veiligheids marges nemen dan waneer een mens het zou hebben gedaan...
Dat is wel heel optimistisch gedacht natuurlijk. Als dat zou was zouden we dingen als ABS in een auto ook niet nodig hebben, als een goede autocoureur altijd slimmer zou zijn dan een script.
Ook in dit geval werkt de optimalisatie waarschijnlijk beter dan de gemiddelde webdeveloper..
Ook in dit geval werkt de optimalisatie waarschijnlijk beter dan de gemiddelde webdeveloper..
Daar ben ik het niet mee eens, met die instelling zou je zelf alles in assembler programmeren, ipv dat je een c++ compiler het werk laat doenmensen zijn altijd slimmer dan scripts
Ja, het zou.. sneller... kunnen zijn... maar in 99% van de gevallen heb je daar echt de tijd niet voor om te doen, plus de kennis die je ervoor nodig hebt is misschien gigantisch..
Vergeet niet dat die mensen die die scripts hebben gemaakt misschien daarin gespecialiseerd zijn, en een geniaal algoritme hebben gemaakt die altijd sneller zal zijn dan als jij, een webdeveloper, dat zelf probeert.
Dit zal echt wel wat meer zijn dan wat ini's aanpassen en wat simpele scriptjes ergens tussen plakken.
[Reactie gewijzigd door marking op donderdag 4 november 2010 14:43]
Daar is eigenlijk niets zinnigs over te zeggen. mod_pagespeed doet eigenlijk alleen iets aan frontend performance, nginx heeft vooral invloed op backend performance, totaal niet vergelijkbaar in iedergeval.
mod_pagespeed zal zorgen dat de pagina iets minder snel naar de gebruiker kan maar in de praktijk is de invloed daarvan marginaal. Vaak heb je in 300ms ook een dynamische pagina wel klaar, meeste tijd zit echter bij de client die daarna tig css en js files moet downloaden, parsen, etc. mod_pagespeed zorgt ervoor dat het werk aan de client-kant flink verminderd wordt.
Maar goed, appels met peren dus Op zich wel een leuke module, natuurlijk beter om dit soort dingen zelf te doen in je code maar dat is lang niet altijd een optie en vaak ook behoorlijk wat werk als je een off the shelve cms gebruikt b.v.
mod_pagespeed zal zorgen dat de pagina iets minder snel naar de gebruiker kan maar in de praktijk is de invloed daarvan marginaal. Vaak heb je in 300ms ook een dynamische pagina wel klaar, meeste tijd zit echter bij de client die daarna tig css en js files moet downloaden, parsen, etc. mod_pagespeed zorgt ervoor dat het werk aan de client-kant flink verminderd wordt.
Maar goed, appels met peren dus
Op zich wel een leuke module, natuurlijk beter om dit soort dingen zelf te doen in je code maar dat is lang niet altijd een optie en vaak ook behoorlijk wat werk als je een off the shelve cms gebruikt b.v.Bah, niet de source of een package voor FreeBSD 
En voor iemand begint te piepen: FreeBSD wordt heel veel gebruikt in de hostingwereld.
En voor iemand begint te piepen: FreeBSD wordt heel veel gebruikt in de hostingwereld.
Hoezo?
Er is wel degelijk source beschikbaar hoor. Er zijn gewoon een aantal prepackaged modules voor de opgelijste distro's.
Kijk maar naar de FAQ
Are there any restrictions in using Page Speed technology?
The Page Speed code base is governed by the Apache 2.0 Open Source License. You can use Page Speed as determined and allowed by the license.
De source kan je gewoon hier browsen
Er is wel degelijk source beschikbaar hoor. Er zijn gewoon een aantal prepackaged modules voor de opgelijste distro's.
Kijk maar naar de FAQ
Are there any restrictions in using Page Speed technology?
The Page Speed code base is governed by the Apache 2.0 Open Source License. You can use Page Speed as determined and allowed by the license.
De source kan je gewoon hier browsen
Ehh, wat jij daar linkt is de page-speed plugin voor Firefox/Firebug, da's heel wat anders dan de page-speed module voor Apache die hier besproken is.
Edit: de source van de Apache module is hier te vinden: http://code.google.com/p/modpagespeed/source/browse/
Edit: de source van de Apache module is hier te vinden: http://code.google.com/p/modpagespeed/source/browse/
[Reactie gewijzigd door JapyDooge op donderdag 4 november 2010 10:38]
Oeh! thx!
ik ga 'm gelijk compilen.
ik ga 'm gelijk compilen.
Lijkt me wel interessant als dit meegenomen wordt in de ports tree, mocht iemand dat serieus op gaan pakken, dan hoor ik het graag, want we hebben wat sites in beheer die ik er best mee zou willen uitrusten.
Dit klinkt een beetje als een front-side proxy. Met Squid en mod_rewrite heb ik soortgelijke truuks +/- 10 jaar geleden al uitgehaald. De versnelling in laadtijd die je dan met dynamische content kunt halen is enorm omdat de browser lokaal plaatjes en andere semi-statische content kan cachen. Als bonus is de server load tot 60% lager.
Beetje met je eens. Op een goed geoptimaliseerde site kun je niet veel winst meer maken. Maar heeel heel veel sites zitten met wat standaard installaties aan elkaar geknoopt, en zolang de serverload acceptabel is wordt er niet geoptimliseerd. Daar deze mod laden is pure winst.
Waarschijnlijk kun je aan de applicatie kant nog veel meer winnen, maar veel kleine sites hebben niet de tijd om dit te optimaliseren.
Waarschijnlijk kun je aan de applicatie kant nog veel meer winnen, maar veel kleine sites hebben niet de tijd om dit te optimaliseren.
Heeft dat gevolgen voor de verzonden hoeveelheid data?
Uiteraard. Stel een pagina bevat 1000 'onnodige' whitespaces, dan haal je door die weg te halen al 1000 bytes van elke request af (als de pagina niet gecompirmeerd verstuurt wordt!). Hetzelfde gaat op voor de css en js minification, en het compressen van images.
Ja, want er wordt meer en slimmer lokaal bij gebruikers opgeslagen, waardoor er minder data naar de gebruiker verzonden hoeft te worden.
Ah hier ben ik wel blij mee. Het wordt langzamerhand iritant dat websites steeds uitgebreider worden, puur omdat je nu niet meer lekker door kan klikken.
Als MS fanboy moet ik met pijn in mijn hard toegeven dat vooral de community websites van MS echt zoooo traag laden dat ik er minder vaak kom
Als MS fanboy moet ik met pijn in mijn hard toegeven dat vooral de community websites van MS echt zoooo traag laden dat ik er minder vaak kom
Ik vrees dat de websites van MS niet op een apache webserver zullen draaien, maar IIS 
'Fanboy' is vrij negatief hoor, zoek maar op. Je kan jezelf ook gewoon 'tevreden Microsoft-product-gebruiker' noemen.
Een aantal van de web-sites van Microsoft draait al op Apache of in ieder geval Linux, dat hebben ze namelijk uitbesteed aan Akamai.
Maar je kan prima een Apache-proxy maken voor een IIS-webserver.
mod_security /ssl-offloading, etc. is vast ook geen slecht idee.
Maar je kan prima een Apache-proxy maken voor een IIS-webserver.
mod_security /ssl-offloading, etc. is vast ook geen slecht idee.
Slecht gebouwd misschien?
Of niet de ingebouwde cache en van IIS gebruikt?
www.ASP.Net laadt hier trouwens prima
Of niet de ingebouwde cache en van IIS gebruikt?
www.ASP.Net laadt hier trouwens prima
hmm ben benieuwd of dit aanslaat, hosters hebben vaak flinke marges over hun dataverkeer, vooral als je over je limiet heen gaat. Dit kan er dus voor zorgen dat ze er niet zo gauw aan denken dit te implementeren op hun servers, aangezien mensen dan minder snel over hun limit zitten, en dus minder snel inkomsten ervan plukken...
Voor mensen die hun eigen dedicated server(of vps) hebben is dit natuurlijk wel weer kosten besparend. Dus ben benieuwd hoe dit verder ontwikkeld!
Voor mensen die hun eigen dedicated server(of vps) hebben is dit natuurlijk wel weer kosten besparend. Dus ben benieuwd hoe dit verder ontwikkeld!
Een nieuwe server aanschaffen implementeren en onderhouden kost een hoster meer dan dat die paar euro's bandbreedte hem opleveren hoor.
hmm, geld is geld toch? ik zeg dat hosters eraan verdienen, en elke euro lijkt mij mooi mee genomen, dus waarom zouden zij tijd in iets gaan steken wat hun geld kost ipv opleverd? dat is niet logisch...
ik denk dat je redelijk mis gaat hier,
1: door hier gebruik van te maken gebruiken hun users minder data ook minder bandbreedte, hierdoor komt er ruimte voor NOG meer overselling kortom DOEN.
2: niet alle data pakketten zijn gebaseerd op over de limiet heen gaan, er zijn zat mensen die dik onder hun limiet blijven, maar een pakket nemen bijv omdat het goedkopere pakket functie-x niet bied. - zulke klanten met deze module laten werken bied hun bezoekers nog snellere websites, hun bezoekers blij == je klanten blij == jij blij ++ je klanten nog minder data verbruiken == minder kosten == jij blij... kortom weer een DOEN
3: grote klanten die toch al veel opleveren zijn vaak ook van het type 'veel voor weinig' die zullen eerder zeggen xyabc-hosting bied het ook al dus jij ook anders gaan we verhuizen.
dus of je het nu leuk vind of niet, alweer een doen (zelfs al is het dit keer niet in hoofdletters)
dat zijn dus al 3 redenen om het aan te bieden.
1: door hier gebruik van te maken gebruiken hun users minder data ook minder bandbreedte, hierdoor komt er ruimte voor NOG meer overselling kortom DOEN.
2: niet alle data pakketten zijn gebaseerd op over de limiet heen gaan, er zijn zat mensen die dik onder hun limiet blijven, maar een pakket nemen bijv omdat het goedkopere pakket functie-x niet bied. - zulke klanten met deze module laten werken bied hun bezoekers nog snellere websites, hun bezoekers blij == je klanten blij == jij blij ++ je klanten nog minder data verbruiken == minder kosten == jij blij... kortom weer een DOEN
3: grote klanten die toch al veel opleveren zijn vaak ook van het type 'veel voor weinig' die zullen eerder zeggen xyabc-hosting bied het ook al dus jij ook anders gaan we verhuizen.
dus of je het nu leuk vind of niet, alweer een doen (zelfs al is het dit keer niet in hoofdletters)
dat zijn dus al 3 redenen om het aan te bieden.
hmm:
1: Overselling doe ik niet aan, en zou geen enkele hoster moeten doen, het is een feit dat het wel gebeurd, maar elke nette hoster zou dit niet moeten doen. Dus om diet als een "big selling point" noemen vind ik onjuist.
2: je klanten nog minder data verbruiken == minder kosten !== jij blij...
3: echte grote klanten zitten op een eigen server of vps en kunnen het systeem aanpassen, hierop zijn ze vrij om mee te doen en laten wat ze willen... zoals ik al aangaf in mijn eerste post.
1: Overselling doe ik niet aan, en zou geen enkele hoster moeten doen, het is een feit dat het wel gebeurd, maar elke nette hoster zou dit niet moeten doen. Dus om diet als een "big selling point" noemen vind ik onjuist.
2: je klanten nog minder data verbruiken == minder kosten !== jij blij...
3: echte grote klanten zitten op een eigen server of vps en kunnen het systeem aanpassen, hierop zijn ze vrij om mee te doen en laten wat ze willen... zoals ik al aangaf in mijn eerste post.
Zo zeg! Een module welke ik zeker een keer wil gaan toepassen.
Zeker het combineren van CSS bestanden en minify van Javasscript bestanden ziet er goed uit.
Dit zijn goede aanvullingen op Apache!
Zeker het combineren van CSS bestanden en minify van Javasscript bestanden ziet er goed uit.
Dit zijn goede aanvullingen op Apache!
Ik dacht dat Google vooral Lighttpd gebruikte? Maar goed, dat neemt niet weg dat ze Apache sneller willen hebben.
Google gebruikt gws (aka Google Web Server). Gws zou een fork van Apache HTTPD zijn, maar daar is geen duidelijke informatie over.
Wat er over bekend is was Youtube deels op basis van Python/mysql/mod_cgi en ik dacht lighttpd voor video's.
Of dat nog zo is is niet bekend, wel is het dat Youtube op dit moment zegt dat hij Apache is.
Of dat nog zo is is niet bekend, wel is het dat Youtube op dit moment zegt dat hij Apache is.
De aanbevelingen die Google doet bij mod_pagespeed om de performance te verbeteren hebben nogal wat nadelen. Een aantal ervan staat haaks op best practices voor goed programmeren en gestructureerde website bouw. Sommige andere zijn niet bevorderlijk voor een open web en voor het delen van informatie.
Het samenpersen van javascript en css bijvoorbeeld, toch een beetje een treurige aangelegenheid. Zoveel weegt dat niet vandaag de dag, vooral niet als het toch al door gzip is gejaagd. Alle code in een bestand stoppen om het aantal requests te beperken is op pagina-niveau misschien wel slim maar het kan op site niveau weer erg nadelig zijn. Kortom, zelf blijven nadenken.
Het samenpersen van javascript en css bijvoorbeeld, toch een beetje een treurige aangelegenheid. Zoveel weegt dat niet vandaag de dag, vooral niet als het toch al door gzip is gejaagd. Alle code in een bestand stoppen om het aantal requests te beperken is op pagina-niveau misschien wel slim maar het kan op site niveau weer erg nadelig zijn. Kortom, zelf blijven nadenken.
Volgens mij snap je niet helemaal goed wat mod_pagespeed doet. Het is juist bevorderlijk voor goed programmeren, omdat je zelf geen ranzige oplossingen hoeft te implementeren om tot dezelfde resultaten te komen. In plaats daarvan zorgt mod_pagespeed er automatisch, onzichtbaar en non-destructive voor dat dergelijke aanbevelingen worden doorgevoerd in de HTML, CSS en JavaScript die worden geserveerd, zonder de onderliggende code en pagina's aan te passen.
Verder hebben de maatregelen die ze nemen wel degelijk ernstige impact, vergeet niet dat niet iedereen een 100 Mbit-verbinding heeft, en dat elke byte bespaard veel kan schelen, zeker aan de serverkant, als je al die requests bij elkaar optelt.
Verder hebben de maatregelen die ze nemen wel degelijk ernstige impact, vergeet niet dat niet iedereen een 100 Mbit-verbinding heeft, en dat elke byte bespaard veel kan schelen, zeker aan de serverkant, als je al die requests bij elkaar optelt.
Ranzige oplossingen moet je zelf inderdaad ook niet implementeren.
Een css file opschonen doe je natuurlijk niet bij ieder page request op een server, Dat is waanzinnig inefficiënt. OK, minder inefficiënt dan de rommel ook nog eens naar een browser te sturen. Een analyse-tool dat bekijkt welke tags niet meer in gebruik zijn in een site is slimmer. Gestructureerd werken ook.
Verder kun je meestal beter één keer een css sturen met de inhoud voor een aantal pagina's van de site dan voor iedere pagina opnieuw weer een maatwerk css, met daarin veel overlap. Maar die analyse gaat mod_pagespeed niet voor je maken.
Dat een css parsen door een browser veel tijd kost wanneer daar wat meer globale selectors in worden gebruikt - daarvoor zijn die dingen en een beetje browser doet dat razendsnel. Wil je dat vermijden, ga gewoon weer html 3 schrijven.
In de webstandaarden is gekozen voor het versturen van door mensen leesbare code. Om je dan druk te gaan maken over een paar spaties, ach gut. Gebruik mod_gzip en klaar. Voordeel: kennis kan gedeeld worden.
Dan is er nog het enorme risico dat mod_pagespeed fouten maakt. Omdat je de optimalisaties niet kunt volgen is dat bijna niet te debuggen. Ik heb ook mijn twijfels bij de mogelijkheden. Ik kan me niet voorstellen dat mod-pagespeed kan snappen welke css-eigenschappen ik nog vanuit javascript aanroep in een pagina. Al met al moet je echt afwegen of de beperkte voordelen opwegen tegen de nadelen en risico's. En is zuiver werken vaak een betere weg.
Een css file opschonen doe je natuurlijk niet bij ieder page request op een server, Dat is waanzinnig inefficiënt. OK, minder inefficiënt dan de rommel ook nog eens naar een browser te sturen. Een analyse-tool dat bekijkt welke tags niet meer in gebruik zijn in een site is slimmer. Gestructureerd werken ook.
Verder kun je meestal beter één keer een css sturen met de inhoud voor een aantal pagina's van de site dan voor iedere pagina opnieuw weer een maatwerk css, met daarin veel overlap. Maar die analyse gaat mod_pagespeed niet voor je maken.
Dat een css parsen door een browser veel tijd kost wanneer daar wat meer globale selectors in worden gebruikt - daarvoor zijn die dingen en een beetje browser doet dat razendsnel. Wil je dat vermijden, ga gewoon weer html 3 schrijven.
In de webstandaarden is gekozen voor het versturen van door mensen leesbare code. Om je dan druk te gaan maken over een paar spaties, ach gut. Gebruik mod_gzip en klaar. Voordeel: kennis kan gedeeld worden.
Dan is er nog het enorme risico dat mod_pagespeed fouten maakt. Omdat je de optimalisaties niet kunt volgen is dat bijna niet te debuggen. Ik heb ook mijn twijfels bij de mogelijkheden. Ik kan me niet voorstellen dat mod-pagespeed kan snappen welke css-eigenschappen ik nog vanuit javascript aanroep in een pagina. Al met al moet je echt afwegen of de beperkte voordelen opwegen tegen de nadelen en risico's. En is zuiver werken vaak een betere weg.
Waar staat dat deze optimalisate voor elke request gebeurt? Google snapt het Web. Als de onderliggende CSS of JS resource een ETag heeft, of een cache hint, dan is de geoptimaliseerde variant ook te cachen.
Google kent ook jouw idee van een gedeelde CSS. Niet alleen snapt deze module dat, hij doet het zelfs automatisch voor grote CSS styles.
Wat betreft die onnodige spaties en mod_gzip: lees weer eens wat Google erover schrijft. mod_gzip moet twee verschillende encodings gebruiken voor "<a href" en <a href". Maar als je de onnodige tweede spatie verwijdert, dan heb je acuut een besparing en is bovendien mod_gzip daarna ook effectiever.
Kortom, jouw claims zijn FUD en zijn al bij voorbaat weerlegd door Google.
Google kent ook jouw idee van een gedeelde CSS. Niet alleen snapt deze module dat, hij doet het zelfs automatisch voor grote CSS styles.
Wat betreft die onnodige spaties en mod_gzip: lees weer eens wat Google erover schrijft. mod_gzip moet twee verschillende encodings gebruiken voor "<a href" en <a href". Maar als je de onnodige tweede spatie verwijdert, dan heb je acuut een besparing en is bovendien mod_gzip daarna ook effectiever.
Kortom, jouw claims zijn FUD en zijn al bij voorbaat weerlegd door Google.
Een gestructueerde website bouwen betekend niet dat je bij deployment geen optimizaties uit mag voeren. Natuurlijk maak je een mooie structuur van javascript files tijdens development, want 1 grote javascript file is niet bruikbaar. Maar op het moment dat je een dsitributable maakt om te deployen prop je zo veel mogelijk in 1 file. En at runtime probeer je ook zo veel mogelijk in 1 file te stoppen.
Het performance verlies zit erin dat je voor losse bestanden ook meerdere (soms losse) connectie opbouwd, en die eerst weer op snelheid moeten komen. De TCP window sizes starten bij iedere connectie weer bij 1.Het samenpersen van javascript en css bijvoorbeeld, toch een beetje een treurige aangelegenheid. Zoveel weegt dat niet vandaag de dag
Vele losse aanvragen kosten in KB's weinig, maar in overhead op de request veel. Juist met veel bandbreedte is dit iets wat je gaat zien.
[Reactie gewijzigd door YaPP op donderdag 4 november 2010 12:59]
HTTP 1.1 ondersteunt pipelining. Daarom is het niet nodig om meerdere connecties op te bouwen. Soms kun je zelfs twee bestanden in 1 IP packet kwijt.
Het is meestal wel nodig, ik ken eigenlijk geen browser die niet heel agressief meerdere connecties open gooit om maar zo veel mogelijk dingen te gelijk te kunnen opvragen/downloaden.
2 bestanden in 1 IP-pakket ? Dat lijkt me best lastig.
Een beetje standaard ethernet frame is 1500 bytes, daar gaat je ip-header van af en je HTTP-headers, een 1x1 pixels GIF is al 800 bytes. Een beetje CSS-bestand gezipped is al grootter.
Misschien 2 304 Not Modified HTTP-headers, dat zou misschien nog passen.
Maar niet als je bijvoorbeeld google analytics gebruikt, want dan krijg je extra cookies.
2 bestanden in 1 IP-pakket ? Dat lijkt me best lastig.
Een beetje standaard ethernet frame is 1500 bytes, daar gaat je ip-header van af en je HTTP-headers, een 1x1 pixels GIF is al 800 bytes. Een beetje CSS-bestand gezipped is al grootter.
Misschien 2 304 Not Modified HTTP-headers, dat zou misschien nog passen.
Maar niet als je bijvoorbeeld google analytics gebruikt, want dan krijg je extra cookies.
[Reactie gewijzigd door Lennie op donderdag 4 november 2010 18:13]
Keepalive bedoel je, het doen van meerdere requests over 1 verbinding. Pipelining voegt daaraan toe dat je gewoon een aantal requests tegelijk verstuurt waardoor de webserver ze meteen allemaal achterelkaar kan serveren zonder steeds op input van de client te wachten.
Probleem met pipelining is alleen... behalve Opera geen hond die het standaard gebruikt. IE schakelt het standaard uit, Firefox schakelt het standaard uit en Chrome ondersteunt het in zijn geheel niet.
@Lennie hierboven: met pipelining kan je prima 2 of meer requests in een TCP pakket kwijt. Het gaat om de request van de client naar de server, en die is gelimiteerd tot iets als "GET /img/blank.gif".
Probleem met pipelining is alleen... behalve Opera geen hond die het standaard gebruikt. IE schakelt het standaard uit, Firefox schakelt het standaard uit en Chrome ondersteunt het in zijn geheel niet.
@Lennie hierboven: met pipelining kan je prima 2 of meer requests in een TCP pakket kwijt. Het gaat om de request van de client naar de server, en die is gelimiteerd tot iets als "GET /img/blank.gif".
[Reactie gewijzigd door _JGC_ op donderdag 4 november 2010 18:26]
Dit is dan een goede reden om de browser-makers en server-makers onder de kont te schoppen.
Als de server aangeeft het te ondersteunen => inschakelen.
Als de server aangeeft het te ondersteunen => inschakelen.
Incompatilbe met oude webservers. 
Op dit item kan niet meer gereageerd worden.
Populair: Tablets Samsung Websites en communities Mobiele telefoons Google Sony Games Microsoft Consoles Microsoft Xbox One
© 1998 - 2013 Tweakers.net B.V. Contact Over Tweakers Jouw privacy Algemene voorwaarden Cookies
Tweakers wordt uitgegeven door De Persgroep en wordt gehost door True
