Raskere nettlesere skaper måleproblemer

Raskere kjøring av JavaScript i moderne nettlesere gjør dagens ytelsestester mindre nøyaktige.

God JavaScript-ytelse i nettlesere er i ferd med å bli en faktor som vil kunne få stor betydning når brukere kan velge nettleser. Dette skyldes at stadig mer innhold på nettet tar i bruk omfattende JavaScript-kode. Dette gjelder ikke minst webapplikasjoner som tilbyr mye av den samme funksjonaliteten man finner i programvare som kjøres lokalt på brukerens PC, for eksempel webbaserte tjenester for e-post, tekstbehandling, regneark og grafikkredigering.

Både Mozilla, Apple/WebKit og Google/WebKit har de siste månedene oppgitt at selskapene jobber intenst med å tilby sterkt forbedret JavaScript-ytelse i kommende nettleserversjoner ved henholdsvis å innføre JavaScript-motorene TraceMonkey, SquirrelFish og V8.

Det arbeides nå med å gjøre V8 og annet Chrome-kode tilgjengelig for WebKit.

Det er gitt ut flere ulike tester som nettleserbrukere kan benytte til å få et inntrykk av blant annet JavaScript-ytelsen til forskjellige nettlesere. Men disse testene er ikke laget for å representere virkelige brukeropplevelser, men forteller i stedet hvor raskt nettleseren er i stand til å utføre en serie små, men vanlige oppgaver.

Nå mener John Resig, JavaScript-evangelist for Mozilla og hovedpersonen bak JavaScript-biblioteket jQuery, at ytelsen til nettleserne er i ferd med å bli så høy at nøyaktigheten til testene blir kraftig redusert. I et blogginnlegg skriver Resig at tester som tidligere tok ganske lang tid å utføre, nå kan gjøres på langt kortere tid. Og når tiden det tar å kjøre testen går betydelig ned, får variasjoner i denne tiden stadig større betydning.

For eksempel, dersom man kjører en test som normalt varer i 10 millisekunder fem ganger, og testen én av disse gangene tar 11 millisekunder å kjøre, så vil denne ene kjøringen introdusere en betydelig feil i de samlede resultatene.

Tester som tar betydelig lenger tid å kjøre, er derimot langt mer nøyaktige. Men med raskere nettlesere, tar det altså stadig kortere tid å kjøre testene, som gjerne er laget med utgangspunkt i ytelsesnivået til nettleserne der og da.

Dette betyr enten at man må kjøre de raske testene langt flere ganger enn tidligere for å få et nøyaktig resultat, eller ta i bruk mer langsomme tester.

JavaScript ytelsestesting - feilmargin i forhold til varighet av test.
JavaScript ytelsestesting - feilmargin i forhold til varighet av test.

Resig mener at dette likevel ikke er nok, fordi ytelsen til nettleserne forbedres raskere enn det testene kan tilpasses til. Resig mener at testene må oppdateres med få måneders mellomrom for å ta hensyn til dette.

Han mener likevel at Google V8 Benchmark tar i bruk en strategi som gir mer stabile resultater.

I stedet for å kjøre hver av deltestene et fast antall ganger, kjøres hver deltest kontinuerlig inntil ett sekund har gått. Dette betyr at antallet ganger deltesten kjøres, avhenger av ytelsen til nettleseren og maskinvaren testen kjøres på.

Men i motsetning til tester som WebKits Sunspider og Mozillas Dromaeo, utfører ikke V8 Benchmark noen form for beregning av feilmarginen til resultatene.

- Siden alle JavaScript-motorer blir raskere og raskere, og komplekse tester kjøres på kortere og kortere tid, er den eneste logiske konklusjonen å behandle alle tester som om de var raskere tester og å kjøre dem et variabelt antall ganger, skriver Resig.

Med utgangspunkt i dette vil han jobbe for at i alle fall Mozilla Dromaeo-test bedre skal ta hensyn til de stadige ytelsesforbedringene til nettleserne, selv om det vil føre til at kjøringen av testsuiten vil ta mye lenger tid.

    Les også:

Til toppen