Js/img op andere domeinnaam zetten voor betere performance?

[StephanVierkant]

Ik ben momenteel bezig om mijn websites te optimaliseren. Zowel om de performance te verbeteren als ook dataverkeer in te perken/inzichtelijker te maken. Zo heeft de 'Page Speed' plugin van Firebug mij al wat tips gegeven, maar ik zit nu toch te twijfelen aan twee van de aanbevelingen.

Zo laad ik de laatste jQuery Core van google.com/jsapi. Dit is dus een extra dns-lookup en dat zou voorkomen moeten worden volgens Page Speed.

Een andere suggestie lijkt juist het omgekeerde te willen: Serve static content from a cookieless domain en Parallelize downloads across hostnames. Zo moet ik al mijn afbeeldingen, css'jes en js's op een andere domeinnaam zetten, die geen cookies gebruikt.

Ik kan me in beide suggesties wel vinden, maar heb het idee dat ze elkaar een beetje bijten. Wie kan hier meer uitleg over geven, of heeft een goede site waar ik meer informatie over kan vinden?

[HuHu]

Je moet het juiste evenwicht vinden tussen de suggesties. Het nadeel van een extra DNS lookup weegt niet op tegen het voordeel van het laden van jQuery vanaf Google. Dus die moet je zo laten.

Het gebruiken van een andere domeinnaam voor statische content is wel slim. Wederom is het nadeel van de extra DNS-lookup te verwaarlozen ten opzichte van de winst voor het laden van je pagina.

Maar je kunt het ook overdrijven. Als je alle statische content vanaf een andere domeinnaam zou laden, dan weegt het voordeel van die apart domeinnaam niet meer op tegen de vele DNS lookups.

Dan kom je dus uit op zoiets:

HTML: example.com
jQuery: google.com/apis
CSS/IMG/JS: exampleimages.com

Het eerste domein gebruik je dan voor je HTML, wat logisch is. jQuery laad je vanaf Google, wat allerlei voordelen biedt. Je statische content haal je van het cookie-loze derde domein.

[StephanVierkant]

Ik ben er nog steeds niet van overtuigd, omdat Google dit ook zegt:

Don't serve early loaded external JS files from the cookieless domain.
For JavaScript referenced in the head of the document and needed for page startup, it should be served from the same hostname as the main document. Because most browsers block other downloads and rendering until all JavaScript files have been downloaded, parsed and executed, it's better to avoid the risk of an additional DNS lookup at this point of processing.

Moet ik nu alleen de afbeeldingen, of ook de js's (die ik trouwens met één bestand zal laden met minify, dus zoveel zal het ook niet uitmaken, hooguit in kb's)?

[RobIII]

Het laden van de afbeeldingen van een ander domein heeft een andere reden: Doorgaans gebruiken browsers max. 2 openstaande connecties per domein host. Als je dus je afbeeldingen van een ander domein host gaat laden heb je 2 connecties "gratis" erbij waardoor de afbeeldingen eerder zullen beginnen te laden en minder in de weg zullen zitten tijdens het laden van de html. Datzelfde geldt natuurlijk ook voor js/css/etc. maar ergens houdt het natuurlijk ook op. Het is gewoon een kwestie van de juiste balans vinden.

[ Voor 3% gewijzigd door RobIII op 29-12-2009 22:52 ]

[burne]

RobIII schreef op dinsdag 29 december 2009 @ 22:14:
Het laden van de afbeeldingen van een ander domein heeft een andere reden: Doorgaans gebruiken browsers max. 2 openstaande connecties per domein.

Per domein of per hostname? Ofwel zou je met static.example.com, script.example.com en www,example.com niet hetzelfde bereiken? Want dat is voor de meeste mensen prima te regelen.

[PaulZ]

Wat ik had begrepen, is dat statische inhoud best wel zonder cookies geserveerd zou kunnen worden. Vandaar dat deze items dan het beste op een server geplaatst worden die deze cookies niet geeft. Eén optie zou dan een CDN zijn (zie Wiki verder).
Ik geef hier maar heel beknopte info, omdat ik niet helemaal zeker van mn zaak ben, maar wel de klepel van de klok door wil geven...

[burne]

PaulZ schreef op dinsdag 29 december 2009 @ 22:21:
Wat ik had begrepen, is dat statische inhoud best wel zonder cookies geserveerd zou kunnen worden. Vandaar dat deze items dan het beste op een server geplaatst worden die deze cookies niet geeft

(Een CDN is dan al snel een dure oplossing.)

Ik heb een paar weken terug wat benchmarks gedraait op m'n (kleine) vmmetje bij een provider. Statisch zonder cookies heb ik geen moeite met een gigabit vullen. De meter bleef steken op 996Mbit/s bij een CPU-load van een paar procent en vrijwel geen geheugengebruik. Met cookies en cache-checks (ik render de meeste php naar pseudo-statische html) daalt dat naar zo'n 440Mbit/s, en zonder cache (dus geparste php) gaat tien maal trager, op 43Mbit/s. Dus statisch helpt echt enorm als je de vrijheid hebt om dat zo op te lossen kan dat enorm helpen voor drukke sites.

[GlowMouse]

burne schreef op dinsdag 29 december 2009 @ 22:34:
[...]

(Een CDN is dan al snel een dure oplossing.)

Ik heb een paar weken terug wat benchmarks gedraait op m'n (kleine) vmmetje bij een provider. Statisch zonder cookies heb ik geen moeite met een gigabit vullen. De meter bleef steken op 996Mbit/s bij een CPU-load van een paar procent en vrijwel geen geheugengebruik. Met cookies en cache-checks (ik render de meeste php naar pseudo-statische html) daalt dat naar zo'n 440Mbit/s, en zonder cache (dus geparste php) gaat tien maal trager, op 43Mbit/s. Dus statisch helpt echt enorm als je de vrijheid hebt om dat zo op te lossen kan dat enorm helpen voor drukke sites.

Zitten die cookie en cache-checks in PHP?

[Voutloos]

@burne: Dit soort optimalisaties gaat juist over requests/seconde ipv bandbreedte, dus je post de verkeerde cijfers.

[ Voor 3% gewijzigd door Voutloos op 29-12-2009 22:49 . Reden: +@Burne ]

[we_are_borg]

burne schreef op dinsdag 29 december 2009 @ 22:20:
[...]

Per domein of per hostname? Ofwel zou je met static.example.com, script.example.com en www,example.com niet hetzelfde bereiken? Want dat is voor de meeste mensen prima te regelen.

Nee dat werk niet een subdomein heeft namelijk nog steeds de beperking van een normaal domein. Ik weet dat tweakers.net met 2 domeinen waarvan 1 plaatjes en dergelijke wordt geserveerd. Het cookie loze domein kan geen subdomein zijn van het hoofd domein, aangezien cookies per host wordt geregeld. Een ander voordeel is dat het cookie loze domein bij veel bezoekers de cookies niet meer verzend dus het bespaard in verzenden.

[crisp]

RobIII schreef op dinsdag 29 december 2009 @ 22:14:
Het laden van de afbeeldingen van een ander domein heeft een andere reden: Doorgaans gebruiken browsers max. 2 openstaande connecties per domein. Als je dus je afbeeldingen van een ander domein gaat laden heb je 2 connecties "gratis" erbij waardoor de afbeeldingen eerder zullen beginnen te laden en minder in de weg zullen zitten tijdens het laden van de html. Datzelfde geldt natuurlijk ook voor js/css/etc. maar ergens houdt het natuurlijk ook op. Het is gewoon een kwestie van de juiste balans vinden.

vziw is het per host, en bijna alle browsers doen tegenwoordig 6-8 simultane connecties (IE < 8 is zo'n beetje de grootste uitzondering). De reden voor een apart domein is meestal, zoals we_are_borg hierboven al aangeeft, om juist te zorgen dat het ook cookie-less is

PaulZ schreef op dinsdag 29 december 2009 @ 22:21:
Wat ik had begrepen, is dat statische inhoud best wel zonder cookies geserveerd zou kunnen worden. Vandaar dat deze items dan het beste op een server geplaatst worden die deze cookies niet geeft. Eén optie zou dan een CDN zijn (zie Wiki verder).
Ik geef hier maar heel beknopte info, omdat ik niet helemaal zeker van mn zaak ben, maar wel de klepel van de klok door wil geven...

Een CDN is eigenlijk enkel een goede oplossing voor high-traffic sites met een grote geografische spreiding van bezoekers.

Stephan4kant schreef op dinsdag 29 december 2009 @ 18:07:
[...]
Zo laad ik de laatste jQuery Core van google.com/jsapi. Dit is dus een extra dns-lookup en dat zou voorkomen moeten worden volgens Page Speed.

Ik zat laatst te kijken naar Webwereld die prototype+scriptaculous laadt van googleapis.com en jQuery van googlecode.com (jazeker, 2 complete frameworks ) en wat me opviel was dat googleapis.com US-centric was (dus juist weer minder geschikt als je veel non-US bezoekers hebt), en dat de tweede waarschijnlijk niet eens bedoelt is om direct code vandaan te linken (geen far-future expires en geen HTTP compressie).

Let dus sowieso op als je libraries/frameworks bij een derde partij vandaan 'haalt'.

[GlowMouse]

Voutloos schreef op dinsdag 29 december 2009 @ 22:39:
Dit soort optimalisaties gaat juist over requests/seconde ipv bandbreedte, dus je post de verkeerde cijfers.

Hoewel offtopic, is de verwerkingstijd van een pagina wel heel relevant voor de gebruikerservaring. Maar als je PHP een beetje goed africht, is dat nauwelijks merkbaar (hier op T.net scheelt het op veel pagina's maar 0.02 seconden).

[Voutloos]

offtopic:
mijn reactie was op burne gericht, maar jij moest zonodig tussendoor.

[RobIII]

crisp schreef op dinsdag 29 december 2009 @ 22:47:
vziw is het per host

Oh crap, my bad. Knew that one.

crisp schreef op dinsdag 29 december 2009 @ 22:47:
en bijna alle browsers doen tegenwoordig 6-8 simultane connecties

Hmm, dropped the ball right there. Is dat zo? Ik dacht dat het nog wel gangbaar was. Then again, de info die ik erover heb stamt wel nog uit de IE6 tijd Dus thanks voor de bijscholing
* RobIII even wat stuff gaat lezen.

crisp schreef op dinsdag 29 december 2009 @ 22:47:
De reden voor een apart domein is meestal, zoals we_are_borg hierboven al aangeeft, om juist te zorgen dat het ook cookie-less is

True. Dat had er wel even bij gemogen.

[ Voor 22% gewijzigd door RobIII op 29-12-2009 22:52 ]

[crisp]

RobIII: http://www.stevesouders.c...-on-parallel-connections/

[GlowMouse]

crisp schreef op dinsdag 29 december 2009 @ 22:47:
[...]

Ik zat laatst te kijken naar Webwereld die prototype+scriptaculous laadt van googleapis.com en jQuery van googlecode.com (jazeker, 2 complete frameworks ) en wat me opviel was dat googleapis.com US-centric was (dus juist weer minder geschikt als je veel non-US bezoekers hebt), en dat de tweede waarschijnlijk niet eens bedoelt is om direct code vandaan te linken (geen far-future expires en geen HTTP compressie).

Let dus sowieso op als je libraries/frameworks bij een derde partij vandaan 'haalt'.

jQuery moet je halen van http://ajax.googleapis.co...query/1.3.2/jquery.min.js
Hét grote voordeel komt pas wanneer veel sites hiernaartoe linken. Je hoeft dan maar één versie in je cache in te laden voor alle sites die het gebruiken.
De latency naar googleapis.com is erg laag hier, dus ik denk toch niet dat ik verbinding maak met een server uit de VS.

[CH4OS]

GlowMouse schreef op dinsdag 29 december 2009 @ 22:56:
jQuery moet je halen van http://ajax.googleapis.co...query/1.3.2/jquery.min.js
Hét grote voordeel komt pas wanneer veel sites hiernaartoe linken. Je hoeft dan maar één versie in je cache in te laden voor alle sites die het gebruiken.
De latency naar googleapis.com is erg laag hier, dus ik denk toch niet dat ik verbinding maak met een server uit de VS.

Alleen verwijs je dan keihard naar een vaste versie, stel er komt een update van jQuery, dan moet je dat op al je sites weer gaan updaten, wat me ook niet handig lijkt.

[crisp]

GlowMouse schreef op dinsdag 29 december 2009 @ 22:56:
[...]

jQuery moet je halen van http://ajax.googleapis.co...query/1.3.2/jquery.min.js

Jep, googleapis.com is daar ook voor bedoelt.

Hét grote voordeel komt pas wanneer veel sites hiernaartoe linken. Je hoeft dan maar één versie in je cache in te laden voor alle sites die het gebruiken.

True, maar de vraag is of dat ook gebeurd, en al op voldoende schaal dat je dat voordeel ook echt hebt...

De latency naar googleapis.com is erg laag hier, dus ik denk toch niet dat ik verbinding maak met een server uit de VS.

Ik heb toen gewoon een trace gedaan en kwam wel in de US uit; dat kan toeval geweest zijn en ik heb het verder niet echt onderzocht - wij gebruiken toch geen externe frameworks

GJtje schreef op dinsdag 29 december 2009 @ 23:07:
[...]
Alleen verwijs je dan keihard naar een vaste versie, stel er komt een update van jQuery, dan moet je dat op al je sites weer gaan updaten, wat me ook niet handig lijkt.

De spreiding over verschillende versies doet het cache-voordeel natuurlijk ook weer deels teniet...

Het cache-voordeel geloof ik dus niet zo in. Ik denk dat dat voordeel slechts opgaat voor een zeer klein aantal 'first-visitors'. Ik heb daar geen harde cijfers van, maar het is een gut-feeling zeg maar.

[ Voor 25% gewijzigd door crisp op 29-12-2009 23:21 ]

[CH4OS]

crisp schreef op dinsdag 29 december 2009 @ 23:08:
De spreiding over verschillende versies doet het cache-voordeel natuurlijk ook weer deels teniet...

Stel, het zou staan op apis.google.com/js/jquery/lastest.min.js (is even fictieve adres), dan laadt de browser altijd de laatste versie neem ik aan en maakt het toch ook niet uit voor de cache, eerder dan voor de headers, last-modified e.d.? Al hef je het door jou aangekaarte probleem dan wel deels op natuurlijk.

[ Voor 7% gewijzigd door CH4OS op 29-12-2009 23:33 ]

[GlowMouse]

GJtje schreef op dinsdag 29 december 2009 @ 23:33:
[...]
Stel, het zou staan op apis.google.com/js/jquery/lastest.min.js (is even fictieve adres), dan laadt de browser altijd de laatste versie neem ik aan en maakt het toch ook niet uit voor de cache, eerder dan voor de headers, last-modified e.d.? Al hef je het door jou aangekaarte probleem dan wel deels op natuurlijk.

En dan krijg je problemen als een versie niet backward-compatible is. Dit is iets waarbij je met een paar grote sites moet afspreken om het te gebruiken en dan ook de updates te coördineren.

[RaZ]

GJtje schreef op dinsdag 29 december 2009 @ 23:33:
[...]
Stel, het zou staan op apis.google.com/js/jquery/lastest.min.js (is even fictieve adres), dan laadt de browser altijd de laatste versie neem ik aan en maakt het toch ook niet uit voor de cache, eerder dan voor de headers, last-modified e.d.? Al hef je het door jou aangekaarte probleem dan wel deels op natuurlijk.

En wat doe je dan als de nieuwste versie dusdanig 'vernieuwd' is dat er functies weg zijn, of er veranderingen in paramters zijn. Dan werkt het gelijk niet meer.

Een nieuwe versie hoeft niet altijd 100% backwards compatible te zijn.

Zo zijn er overal wel dingen te vinden waarbij een nieuwe versie andere zaken sloopt. Dat wil je als webmaster natuurlijk wel zelf in de hand hebben natuurlijk.

[RobIII]

GJtje schreef op dinsdag 29 december 2009 @ 23:33:
[...]
Stel, het zou staan op apis.google.com/js/jquery/lastest.min.js (is even fictieve adres), dan laadt de browser altijd de laatste versie neem ik aan en maakt het toch ook niet uit voor de cache, eerder dan voor de headers, last-modified e.d.? Al hef je het door jou aangekaarte probleem dan wel deels op natuurlijk.

Het zou alleen niet zo slim zijn altijd te vertrouwen op de laatste versie. Wat als er wijzigingen zijn gemaakt die jouw site op z'n bek doen gaan? Nu zal dat zeker niet altijd bewust gedaan worden, maar nieuwe versies ontstaan natuurlijk niet voor niets; er zitten zo nu en dan bugs in (of er worden aanpassingen of uitbreidingen gemaakt).

[crisp]

En andersom geldt natuurlijk ook: googleapis zet natuurlijk far-future expire-headers. Bij een dergelijk scenario kan je dus ook niet zomaar gebruik gaan maken van features van een nieuwere versie omdat de kans groot is dat een bezoeker nog een oudere versie gecached heeft die die features niet heeft, en dankzij de far-future expires niet de nieuwe versie ophaalt.

[Gomez12]

GJtje schreef op dinsdag 29 december 2009 @ 23:33:
[...]
Stel, het zou staan op apis.google.com/js/jquery/lastest.min.js (is even fictieve adres), dan laadt de browser altijd de laatste versie neem ik aan en maakt het toch ook niet uit voor de cache, eerder dan voor de headers, last-modified e.d.? Al hef je het door jou aangekaarte probleem dan wel deels op natuurlijk.

Krijg je enkel het andere probleem dat als er een nieuwe versie is hoe krijg je die dan bij je gebruikers...
Je far-future expire dates zeggen dat er nog niet eens gecontroleerd hoeft te worden, dus de cache-versie wordt gebruikt.

@TS : Sowieso kost een DNS-lookup naar google vrij weinig ( voor een dns-lookup ), die telt maar gedeeltelijk mee want google hangt bij zo ongeveer alle google bezoekers nog wel in de dns-cache en als je adwords oid gebruikt dan heb je die dns-lookup toch al.

[PaulZ]

Werkt Google apis niet gewoon met versienummers die je op kan geven? Of lees ik Google en deze weblog verkeerd?
Scheelt misschien een hoop discussie.

[RobIII]

PaulZ schreef op woensdag 30 december 2009 @ 00:26:
Werkt Google apis niet gewoon met versienummers die je op kan geven? Of lees ik Google en deze weblog verkeerd?
Scheelt misschien een hoop discussie.

Het waren dan ook reacties op GJtje in "Js/img op andere domeinnaam zetten voor ..."