Je probleem is - zoals je zelf al aangeeft - dat het begrip "snelheid" niet strak gedefinieerd is, en dat datgene waar jij in geinteresseerd bent niet datgene is wat veel van de beschikbare tools meten.
Op zich ben je al een heel eind op weg door hier zelf een definitie te geven van wat jij wilt
Grof gezegd kun je "snelheid" zien als de combinatie van bandbreedte per thread, aantal threads en latency over de verbinding, en dat in beide richtingen. Welk van die factoren dominant is, hangt af van wat je toepassing is - en dat kan verrassend divers zijn. Extremen zijn enerzijnds realtime toepassingen zoals VoIP waar bandbreedte per thread van verwaarloosbaar belang is maar latency fundamenteel in beide richtingen, en anderzijds totale bulkverkeer als NNTP (nieuwsgroepen) waar latency irrelevant is maar totale bandbreedte over alle threads in één richting volledig bepalend is. Je zou NNTP kunnen doen met USB-sticks en postduiven en het verschil met kleine low-latency pakketten zou niet opvallen
De meeste speedtests focussen op dat laatste. Daar zijn verschillende redenen voor te noemen; marketingtechnisch levert dat de grootste getallen op, maar het is ook een definitie die iedereen snapt, en bovendien is een flink deel van de mensen die geinteresseerd is in snelheid primair geinteresseerd in snelheid van grote downloads.
Jij wilt een benchmark van browse-gedrag. Begrijpelijk, maar tegelijkertijd ook het moeilijkst om te definieren. Bij browsen komt een andere factor kijken, namelijk de DNS performance: hoe lang duurt het om een domain name naar IP te resolven. Maar de mix van factoren...
Kijk voor de grap eens hoe lang het duurt om vier pagina's te laden:
1)
www.watbenjedan.nl (9 regels HTML)
2)
Deze thread (Grote DB-based site, maar kleine pagina)
3) 4Chan /b/ (Site met grote pagina's vol "random" links, die dus op verschillende servers met verschillende performance op verschillende domeinen gehost worden)
4) maps.google.com (Ajax showcase, met sloten communicatie zonder nieuwe requests)
Moge duidelijk zijn dat elk van de drie sites andere performance heeft, andere bottlenecks heeft en dus dat een benchmark die voor de een geoptimaliseerd is voor de ander niet noodzakelijkerwijs relevant is.
Vervolgens moet je ook nog eens naar de keten kijken:
- Software op server
- Hardware server
- Verbinding van server naar internet
- Pad over internet van server naar client
- Internetverbinding van client
- DNS van client (hoeft niet zelfde te zijn als internetverbinding)
- Router, WiFi en andere LAN-meuk van client.
- Hardware van client
- OS van client
- Toepassing van client
Elk van deze dingen kan in potentie performance bottlenecken, en die bottleneck kan permanent (harde limiet) of tijdelijk (capaciteit op piekmomenten) van aard zijn. Welke benchmark je wilt hangt ook af van wat je wilt testen.
Dat is vooral wat je denk ik nog moet bepalen: wil je het verschil meten tussen browsers op dezelfde PC of tussen PCs/andere devices op je netwerk, wil je de performance van je ISP bijhouden, wil je de performance van één specifieke website in de gaten houden, of wil je iets anders?
Gezien hoe onnoemelijk veel variabelen er zijn, ontkom je er niet aan om zelf een testscript in elkaar te flanzen. Dat hoeft niet ingewikkelder te zijn dan een opdracht om in een gestarte browser *iets* te doen en dat te timen. In veel gevallen zijn er ook plugins beschikbaar ervoor. Maar het staat of valt met de definities
Allicht kunnen wij je helpen als je daar specifieker in bent
:strip_exif()/u/26632/dosprompt2.gif?f=community)
/u/12038/crop5a51514a4dec1_cropped.png?f=community)