- Dit onderwerp is leeg.
-
Berichten
-
-
In de volgende video laat Google woordvoerder Matt Cutts weten dat de laadsnelheid van websites een factor van belang gaat worden in het bepalen van de rankings ervan:
Video: Matt Cutts Gives More Caffeine Details, Talks Site Speed
De video gaat overigens voor het grootste deel over de uitrol van Google Caffeine. Ook interessant.
-
Ja interessante video! Laadsnelheden was al eerder aangekondigd, maar nog niet zo nadrukkelijk. Via Google Webmaster tools kun je kijken hoe lang de Google bot erover doet om je pagina in te lezen. Daarnaast kun zijn tools als Firefox extensie YSlow goed om te kijken hoe snel je website is en waar je verbeteringen door kunt voeren.
Snelheid is dus een belangrijke factor bij het kiezen voor hosting en een CMS systeem. Het CMS dat wij gebruiken (Drupal) comprimeert bijvoorbeeld externe JS en CSS bestanden zodat er minder requests naar de server hoeven te gaan.
-
Even wat vraagjes, Taco.
1. Hoezo moeten er minder requests naar de server als de bestanden zijn gecomprimeerd? Ik kan alleen zien dat gecomprimeerde bestanden sneller kunnen worden opgehaald omdat ze kleiner zijn.
2. En waar vindt het decompressen plaats? In de browser? -
Goede vraag, ik was wellicht niet helemaal duidelijk genoeg.
Drupal comprimeert witruimtes in de CSS. Maar daarnaast worden de bestanden ook geaggregeeert of samengevoegd (van aggregation). Als laatste wordt gebruik gemaakt van CSS Sprites. Dit alles gebeurd serverside.Tegenwoordig hebben grotere sites verschillende CSS en JS bestanden die extern worden ingeladen in de HEAD van een website. Elk request hiervoor naar de server kost tijd.
Drupal kan automatisch externe bronnen zoals CSS en JavaScript
optimaliseren, wat zowel de grootte als het aantal aanvragen aan uw
website kan verminderen. CSS-bestanden kunnen samengevoegd en
gecomprimeerd worden tot één enkel bestand, terwijl
JavaScript-bestanden samengevoegd (maar niet gecomprimeerd) worden.
Deze optimalisaties zijn optioneel en kunnen de serverbelasting,
benodigde bandbreedte en paginalaadtijden verminderen.Hoe ziet dit eruit in de praktijk?
1) Zonder Bandbreedte-optimalisatie:
HTTP Requests – 54
Total Weight – 211.9K2) Met Bandbreedte-optimalisatie:
HTTP Requests – 39
Total Weight – 204.7KDit gaat dus niet zozeer om de grote van je pagina, maar puur om het aantal requests. Dit kan aardig oplopen in laadtijd besparing.
Een zeer goed artikel hierover mbt Drupal staat op:
Improving Drupal’s page loading performance | Wim LeersDaarnaast heeft de Yahoo! Yslow tool zeer veel uitleg om je pagina nog sneller te laden! Zo gebruiken we ook Smush.It™ om plaatjes te verkleinen.
Succes! -
Helder, dank.
Ik neem aan dat er na bandbreedte-optimalisatie twee requests nodig zijn, één voor de (samengevoegde) .css en één voor de (samengevoegde) .js?
-
Dat klopt dit zijn nu twee requests. Elk plaatje is er bijvoorbeeld nog eentje. En nog twee naar Google Analytics etc. Zo zitten we toch nog op 39 requests voor GoalGorilla.com.
Om dit verder terug te dringen kun je bijvoorbeeld heel veel plaatjes in één plaatje stoppen en deze in een keer inladen. Dit doen grote sites zoals YouTube dan ook: http://s.ytimg.com/yt/img/master-vfl125983.png
-
Interessant.
Ik zie dat ytimg een domein is van youtube via welke -naar ik aanneem- de images uitgepakt kunnen worden uit dat ene .png bestand.
Maar hoe kunnen wij dat met onze website doen? Het zou bijvoorbeeld mooi zijn als je door een argument mee te geven aan de .png de specifieke image eruit kan halen. Maar dan moet het .png-formaat dat wel ondersteunen, en ik heb geen idee of dat zo is. M.a.w. wat is een goede manier?
-
Ik ben helaas geen designer, het heeft te maken met het volgende op YouTube:
.yt-uix-expander-arrow{ height:16px; width:12px ;margin-right:4px; background:url(http://s.ytimg.com/yt/img/master-vfl125983.png) no-repeat 0 -322px; }Dit wordt ook wel PNG masking en positioning genoemd. Misschien zijn er nog desginers op het forum die hier meer van weten..?
-
Ja, je legt met css in principe een masker over het gehele plaatje en laat dat alleen dat deel zien dat op -322px staat. Zo kun je toe met 1 plaatje en alles vanuit dat ene plaatje vormgeven.
Overigens moet je met die kleine plaatjes wel voorkomen dat je niet meer bytes aan css code schrijft dan dat zo’n plaatje qua omvang zou zijn want dan behaal je het tegenovergestelde resultaat 🙂
Overigens begint het hele snelheidsverhaal met een goed gestructureerde en netjes gecodeerde website. Dat laat nog wel eens te wensen over. Als je je strict houdt aan de XHTML/css scheiding en modellering heb je in de basis al een zeer snelle website.
Daarna is optimalisatie voor snelheid op je productie platform uiteraard altijd gewenst. YSlow is daar buitengewoon handig bij.
-
@site-maker, we hadden het over het verminderen van het aantal HTTP requests. Stel je website wordt door CSS aanpassingen 30 Kb groter, maar je verminder het aantal requests door de plaatjes te mergen met 20, dan is dit nog steeds erg gunstig voor je laadtijd..
-
-
Overigens in verband hiermee is dit ook een leuk stukje: Inline Images with Data URLs – embed graphics inline with data uri scheme data-urls zorgen straks voor nog minder HTTP Requests. Maar aangezien er nog veel met IE6-7 gewerkt wordt zal er eerst omheen gewerkt moeten worden.
-
-
Ja, het zou leuk zijn als we daar iets zinnigs over konden zeggen. Probleem is dat je daar moeilijk een absoluut getal aan kan hangen, omdat het van zoveel verschillende factoren afhankelijk is. Bijvoorbeeld: van waaruit vindt de test plaats? Hoe is de kwaliteit van de verbinding op het moment van testen? Hoe zwaar wordt de server op dat moment toevallig belast voor andere websites? Etc., etc.
Daarom is het getal wat YSlow geeft (achter het tabblad ‘Statistics’) misschien nog wel het meest objectief, namelijk het aantal ‘http requests’ en de ’total weight’ (kb), bij een empty cache (want Google komt langs met een lege cache).
In het geval van de seoguru-homepage zijn dat 28 requests bij een weight van 128.1k.
De homepage van dit forum komt uit op 32 requests bij een weight van 141.3kMaar als er een hele langzame of drukke server achter hangt, dan hebben we aan deze getallen niet genoeg. Mooiste zou zijn als er vanaf 1 punt gemeten kon worden. Alexa heeft wel zo’n service, alwaar ik voor mijn website lees:
Average Load Time for Seoguru.nl
Very Fast (0.836 Seconds), 88% of sites are slower.Maar hoe representatief deze meting is weet ik niet.
Tot slot wil ik nog even verwijzen naar de volgende Google-uithoek waar van alles te vinden is over het versnellen van websites: Let's make the web faster – Google Code
-
In navolging van Google’s aankondiging om de snelheid van de website een factor te laten worden in het bepalen van de rankings, zijn aan Webmaster Tools (onder de optie ‘Lab’) ‘siteprestaties’ toegevoegd. Daarmee is in één oogopslag te zien hoe de site presteert, mn. in verhouding tot andere sites. Het lijkt er op dat we in het groene, ‘snelle’ gebied, m.a.w. bij de categorie 20% snelste websites, moeten zien te komen.
Dit relatieve snelheidscriterium is een slimme truc van Google. Er zal een snelheidsrace gaan ontstaan. We kunnen vandaag een website hebben die snel genoeg is, maar morgen kan dit weer anders zijn. We zullen moeten blijven investeren in snelheid om bij de 20% snelste websites te blijven.
-
-
Oei.
Dit kan een probleem gaan leveren, hoopt niet dat het een al te hoog tellend factoor word! :rolleyes:
-
Gestart:51
Reacties:106Hi, een van de internet snelheid en IP-informatie, gebruik ik deze gratis site http://www.ip-details.com/ alleen voor mijn snelheid en IP-informatie, bezoek hier voor meer informatie.
-
Je moet ingelogd zijn om een antwoord op dit onderwerp te kunnen geven.