Google Page Speed-tool nu ook online beschikbaar

Google heeft donderdag een webversie van zijn Page Speed-tool uitgebracht. Google Page Speed Online is bereikbaar vanuit iedere browser. De tool analyseert de prestaties van websites en geeft vervolgens suggesties om die te verbeteren.

Google heeft bij de introductie van Page Speed Online ook nieuwe features toegevoegd, zo meldt het bedrijf op zijn blog. Het is nu bijvoorbeeld mogelijk om specifieke suggesties te krijgen voor de mobiele versie van een internetpagina. Google vindt deze toevoeging belangrijk, omdat het gebruik van mobiele apparatuur snel toeneemt. Bij het analyseren van dit soort pagina's wordt extra gelet op zaken als het niet kunnen cachen van 'landing page redirects' en het verminderen van de hoeveelheid javascript die wordt geparsed tijdens het laden van een pagina.

Op 22 maart werd Page Speed nog beschikbaar gemaakt voor Chrome. Bij deze versie werd het toekennen van scores aan internetpagina's en het op prioriteit indelen van optimalisaties toegevoegd. Tevens ondersteunt Page Speed sinds die update maar liefst veertig talen. Een Firefox-add-on voor Page Speed bestond al langer. Google gaf toen ook aan dat inmiddels 1,4 miljoen unieke gebruikers Page Speed hebben benut.

Reacties (48)

[Timons106]

Haha geniaal! Moet je bij de URL http://pagespeed.googlelabs.com/ invullen xD.
Dan vliegt het logo weg .
Mijn website scoort 78, best tevreden daarmee.

[Beerkeeper]

Dat is pas handig! Nu kom je redelijk 'onafhankelijk' erachter hoe je website performed vanuit de buitenwereld gezien.

Dat je code snel is, is 1. Hoe de rest van de pagina door de lijn wordt gepompt is 2, en dat zie je nu

[ACM]

Dat kon al, en veel uitgebreider, met de Yslow en Page Speed plugins voor Firefox. Of met de online omgeving http://www.webpagetest.org/

Page Speed Online van Google lijkt nog wat beperkt in zijn functionaliteit tov webpagetest.

[Lisadr]

Nu.nl scoort 39 terwijl het super snel laad, maar andere sites met een score van 92+ laden veel langzamer.

Dit is geen page speed tool. Dit is een overzicht van technische optimalisatie eisen.

Volgens deze tool heb je een betere score bij het inladen van 2x 1mb CSS bestanden ipv 10x 3kb CSS bestanden.

Werkelijkheid is dat een site met 2mb aan css veel langzamer is dan 30k aan css.

[ACM]

Met jouw extreme voorbeeld zal dat kloppen. Maar 2x 100kB of 10x 3kB zou zomaar in het voordeel van die 2x 100kB kunnen vallen... De connectie-overhead etc zijn namelijk zodanig dat je in dezelfde tijd best veel data kan downloaden Bovendien is de kans groter dat benodigde CSS al in de browser-cache zit voor vervolgbezoeken als je 2x 100KB doet, ipv allemaal losse files.

En inderdaad, een goede score is zeker geen garantie voor goede snelheid. Er is doorgaans wel een correlatie tussen goeie snelheid en een hoge score. Nu.nl heeft bijvoorbeeld erg veel javacript voor allerlei ditjes en datjes, dat helpt niet mee voor een constante goede performance (zeker nu er weer zo'n takeover/fullscreen ad draait bij ze)

[Reactie gewijzigd door ACM op 23 juli 2024 03:09]

[FragNeck]

Summary

The page Tweakers.net - 147.361 bezoekers vand... got an overall Page Speed Score of 75 (out of 100). Learn more

Note that Page Speed Online followed a redirect from http://www.tweakers.net/ and analyzed the page at http://tweakers.net/.

This Page Speed report is generated for this page as it appears in desktop browsers. To get suggestions on how to optimize the performance of this page for mobile devices, generate a mobile report.
Details

Click on the rule names to see suggestions for improvement.

* High priority. These suggestions represent the largest potential performance wins for the least development effort. You should address this item first:
Combine images into CSS sprites
* Medium priority. These suggestions may represent smaller wins or much more work to implement. However, there are no medium priority suggestions for this site. Good job!
* Low priority. These suggestions represent the smallest wins. You should only be concerned with these items after you've handled the higher-priority ones:
Leverage browser caching, Optimize images, Specify a cache validator, Defer parsing of JavaScript, Minify HTML, Remove query strings from static resources
* Rules without suggestions. There are no suggestions for these rules, since this page already follows these best practices. Good job!

[crisp]

Vreemd genoeg geeft Page Speed Online veel lagere scores dan bijvoorbeeld de Firebug Page Speed extentie in Firefox; daar haalt tweakers.net 93/100

Verder zijn de scores als benchmark ook niet zaligmakend; een veel lichtere site zoals bijvoorbeeld mijn tweakblog scoort lager in Page Speed dan de Tnet frontpage, maar wel veel hoger in bijvoorbeeld YSlow...

[bglnelissen]

Tweakers doet het netjes. Het enige commentaar is dat de afbeeldingen moeten worden samengevoegd via CSS sprites.
http://pagespeed.googlela...tweakers.net&mobile=false

[Reactie gewijzigd door bglnelissen op 23 juli 2024 03:09]

[crisp]

Wat we al voor een groot gedeelte doen

[s.stok]

Misschien ook handig om de afbeeldingen (na uploaden) te optimaliseren
http://pagespeed.googlela...false&rule=OptimizeImages

http://developer.yahoo.co...it/faq.html#faq_crushtool


De meeste dingen zijn wel te doen, maar Minify HTML? En dat voor dynamische pagina's dat is erg overdreven en kan je ook grotendeels opvangen met compressie.

[Reactie gewijzigd door s.stok op 23 juli 2024 03:09]

[crisp]

Dat doen we ook voor de plaatjes die we gebruiken binnen de layout. Dit zijn echter plaatjes die zijn geupload door de redactie. We zitten er wel aan te denken om daar serverside nog een automatische optimalisatie op toe te passen (en 15KiB saving is ook niet echt wereldschokkend natuurlijk )

en wat betreft minification: HTTP compressie toepassen als je dat nog niet deed is inderdaad een veel betere eerste stap.

[Reactie gewijzigd door crisp op 23 juli 2024 03:09]

[NitSuA]

ik krijg altijd voor mijn site de volgende melding:

Leverage browser caching

wat ik wil is via een last modifiied datum aan het begin van m'n code aangeven of de caching moet worden ververst. Ik begrijp adhv de toelichting van google toch niet goed hoe ik dit doe. Heeft iemand hier een korte toelichting voor?

[dev10]

Browser Caching heeft niet alleen met de pagina te maken, maar ook met afbeeldingen en dergelijke. Door middel van mod_expires met Apache kun je dit bijvoorbeeld voor elkaar krijgen.

[NitSuA]

ja, dan kan ik alle .jpg bestanden cachen, maar ik wil eigenlijk, aangezien er veel updates zijn, een "last modified" aan het begin van mijn code of in de htaccess, die ik kan verversen wanneer ik aanp[assingen heb gedaan.. tips?

[ACM]

De nieuwe jpg's een nieuwe naam geven en naar die nieuwe naam verwijzen. Dan kan je altijd een hele lange cache-time geven.

Maar dat soort tips zijn vooral bedoeld voor afbeeldingen ter ondersteuning van de layout. Je moet dergelijke tips vooral niet blind toepassen

Voor content-afbeeldingen kan het best heel zinloos zijn om te doen als ze vaak wijzigen en het voor bezoekers dus effectief nauwelijks uitmaakt of je ze nu 1 dag of 365 dagen aan expiry time geeft.

[NitSuA]

maar hetzelfde geldt voor mijn CSS, ik heb geen zin om dit iedere keer dmv een parameter een nieuwe naam te geven, wil gewoon via een last-modified toevoeging werken.. want dat lijkt me toch echt het handigst.

Overigens heb ik gemerkt dat mijn pagina, met een aantal afbeeldingen, minder snel aanvoelt met caching dan zonder caching..

[Mei]

Een idee is een query string aan de src attributes toe te voegen en deze na een update te veranderen, zodat de locatie technisch gezien verandert, maar je je bestanden hun oude naam kan laten behouden.

[crisp]

Dat kost je echter wel een paar Page Speed puntjes: http://code.google.com/sp...html#LeverageProxyCaching - hoewel dat een afweging is die je zelf zal moeten maken. Zelf hebben wij wel gekozen voor timestamps in een GET-parameter

[ACM]

Daar hebben diverse CMS-tools al ondersteuning voor toch? Gewoon automatisch, net als Tweakers.net al doet, een parameter in of achter de naam laten zetten. In ons geval domweg de last-modified tijd.

Dan is het net alsof we steeds een nieuw bestand hebben, maar in werkelijkheid is het hetzelfde bestand met nieuwe inhoud.

[DeuTeRiuM]

?1231237128312 waar 1231237128312 is een timestamp, bijvoorbeeld van de last modified van de css. Volgens mij doet wordpress ook zoiets. Niet dat het dan persee goed is...

[jozuf]

Kijk is naar etags;
http://en.wikipedia.org/wiki/HTTP_ETag

Volgens mij is dat wat je wilt beinvloeden

[roy-t]

Wow, heb net mijn wordpress blogje even geprobeerd en die krijgt gewoon 85 uit 100 (meer dan tweakers.net ). Ik had verwacht dat zoiets als wordpress echt waardeloos zou zijn qua page speed, nouja prima dan hoef ik niets te veranderen.

[Ramoonus]

ligt ook aan je themes, plugins en cache plugins

[Get!em]

ligt vooral aan je theme, plugins en cache

Tevens heb je plugins die specifiek je score verbeteren:
autoptimizer
gzip enablers
htaccess editors

[ACM]

De score is meer een ruwe indicatie of je op de goede weg zit. Het kan prima zijn dat je alsnog een totale paginalaadtijd van meer dan 5 seconde hebt, terwijl je een hele goede score krijgt.
Anderzijds is de score verder niet zo boeiend, vooral de paginalaadtijd is tenslotte van belang. Wel is het zo dat een lage laadtijd normaliter correleert met een hoge score.

[Quad]

En natuurlijk heeft google.nl 100 uit 100

[ApexAlpha]

The page Google got an overall Page Speed Score of 97 (out of 100). Learn more

Blijkbaar is de .com versie langzamer dan de .nl versie!

[Reactie gewijzigd door ApexAlpha op 23 juli 2024 03:09]

[supertheiz]

Lol, voor de bashers:
Microsoft.nl 76/100
Apple.nl 80/100
Ubuntu.com 50/100
Android.com 81/100
Apple.com 78/100
Microsoft.com 78/100

Waarom zitten er bij bijvoorbeeld Microsoft en Apple verschillen tussen de .nl en .com sites? Zijn volgens mij precies dezelfde sites, met een vertaling.

[Reactie gewijzigd door supertheiz op 23 juli 2024 03:09]

[Xirt]

Omdat er ook gekeken wordt naar de manier waarop er doorverwezen wordt tussen de domeinen. Voor Google bijvoorbeeld:

http://www.google.com/ is an uncacheable redirect to http://www.google.nl/

[DannyBevers]

Ziet er niet verkeerd uit had altijd wel weer het probleem om nieuwe browser elke keer weer te openen opzich geen probleem. Maar nu kan ik dat mooi online regelen ben er erg blij mee!