W3C richt werkgroep voor browserprestaties op

Het W3C heeft een werkgroep in het leven geroepen die een methode moet ontwikkelen om de prestaties van browsers objectief te meten. Onder andere Google en Microsoft werken in dit kader aan een gestandaardiseerde api.

Volgens de Web Performance Working Group van het World Wide Web Consortium is het voor webontwikkelaars steeds belangrijker om inzicht te hebben in de prestaties van browsers. Hiertoe moet een universele, objectieve methode worden ontwikkeld om deze prestaties te meten, die in de vorm van een browser-api aan ontwikkelaars ter beschikking moet worden gesteld.

De werkgroep, waarin onder andere Google en Microsoft zitting hebben, wil onder andere kijken naar de webtimings-api van Microsoft. Deze api, die onder andere in Internet Explorer 9 is geïmplementeerd, geeft webontwikkelaars een timingmechanisme waarmee de verwerkingssnelheid van webapps kan worden gemeten. Google heeft een soortgelijk timing-framework ingebouwd in de WebKit-engine die voor Chrome wordt gebruikt.

De twee bedrijven hopen de twee implementaties samen te smeden tot één standaard, zo is op IEBlog te lezen. Volgens de huidige planning moet in oktober 2011 een recommendation uit de bus komen.

Reacties (46)

[mcdronkz]

Heeft dit puur met JavaScript profiling te maken, of ook met rendering van HTML en dergelijke?

Ik vond het overigens niet van stijl getuigen dat jullie over WebKit schrijven, en het vervolgens alleen met Google Chrome in verband brengen. Zoals een ieder hoort te weten, is WebKit nog altijd afkomstig van Apple, en heeft het haar sporen verdiend door de prestaties van wereldformaat die op meerdere platformen met Safari bereikt zijn.

[Reactie gewijzigd door mcdronkz op 27 juli 2024 10:56]

[Anoniem: 349894]

En waar was WebKit ook alweer op gebaseerd? Oh ja, zoals eenieder hoort te weten gebranched uit KHTML en KJS, afkomstig uit het KDE-project. Zullen we die er dan ook maar gelijk bij noemen? KDE heeft zijn sporen ook wel verdiend door de prestaties van wereldformaat die ermee bereikt zijn.

[jbdeiman]

Het lijkt erop dat het over het algemene presteren van de browsers (niet alleen JS, maar ook het renderen van HTML e.d.) en misschien wel de opstarttijd, de efficiëntie waarmee de browser verschillende handelingen doet.

Ik vermoed dus dat het een uitgebreidere profiling is.

[mcdronkz]

De opstarttijd van de browser lijkt me niet bijzonder relevant voor webontwikkelaars, ik kan me dus ook niet voorstellen dat het de moeite waard is om in dergelijke onzinnige materie ook maar enigszins tijd te moeten steken.

[Swerfer]

De opstarttijd van een browser vind ik behoorlijk belangrijk.
Ik start soms wel 30x per dag de browser op en een snelle opstart vind ik persoonlijk dus wel erg belangrijk...

(Ik weet dat je ook gewoon de browservensters open kan laten staan gedurende de dag, maar ik sluit graag alle vensters af als ik achter de pc weg ga...)

[Anoniem: 294537]

Voor u wel. Maar voor een webontwikkelaar maakt het totaal niet uit hoe snel de browser gaat opstarten aangezien ze hier zelf niks aan kunnen veranderen...

[YopY]

Voor u wel. Maar voor een webontwikkelaar maakt het totaal niet uit hoe snel de browser gaat opstarten aangezien ze hier zelf niks aan kunnen veranderen...

Maar voor een webbrowserontwikkelaar wel - en voor die is dit ook belangrijk, omdat je hiermee objectief en gestandaardiseerd de performance van een browser voor een bepaalde set sites kunt meten (ipv de 'wij van WC-eend' benchmarks van tegenwoordig)

[Little Penguin]

Alleen is deze API niet bedoeld voor het meten van de start-snelheid, maar om te meten hoelang er gedaan is over het inlezen van de diverse delen van de website.

Nu kan dat ook wel, door via JavaScript de huidige tijd op te halen aan het begin van de site en aan het einde dit nog een keer te doen en hiervan het verschil te berekenen, maar dat is nogal omslachtig.

Deze API is bedoeld als oplossing en heeft als doelgroep de webontwikkelaar en niet de browserontwikkelaar...

[Xthemes.us]

Alhoewel ik je gelijk geef dat dit helemaal los staat van de starttijd. Een browser met een uur starttijd zal immers in de resultaten hiervan nog steeds met punt op #1 kunnen staan zou ik het ook niet als handig vervangertje voor een aantal javascript functies kunnen zien. Dit heeft toch wel toegang tot wat meer informatie dan javascript, zie dit meer als googles als bijvoorbeeld de extension voor Firefox van google waarmee je kan zien wanneer wat op het scherm word gepaint, een veel lager/dieper niveau van informatie.

Ben wel benieuwd in hoeverre dit nuttig zal zijn voor het doel waarvoor het bedoeld is. Als het in de API van de render engine zit verwerkt wil dat natuurlijk nog niet zeggen dat de uiteindelijke browser niet iets kan toevoegen dat vertragend werkt.

[Anoniem: 80466]

Nu kan dat ook wel, door via JavaScript de huidige tijd op te halen aan het begin van de site en aan het einde dit nog een keer te doen en hiervan het verschil te berekenen, maar dat is nogal omslachtig.

Het is ook volstrekt niet betrouwbaar omdat er geen duidelijke definitie is wat het begin en wat het einde is.

[humbug]

Het is in zoverre betrouwbaar dat een browser elke keer hetzelfde doet waar start en eind precies staan is minder relevant dan dat je een test kan herhalen tijdens het profilen van een applicatie. Zelfs verschillen tussen browsers zijn daarvoor niet relevant.

Deze test functie is dus primair om de browsers zelf te testen. Niet de applicaties.

[Rob Coops]

Als je kijkt naar Google's doel om zo veel mogelijk in de cloud te werken en dus eiegnlijk voor alles je browser te starten omdat het allemaal web-apps zijn bij google dan kan ik me zo voorstellen dat juist ook het meten van opstart tijden erg belangrijk zal worden. Zeker Mozilla is een draak als het gaat om het starten van de browser en ik dnek dat geen van beide (MS of Google) moeite zal hebben met even goedkoop scoren door dat meetbaar te maken in hun API.

Maar de API's die hier worden aangeduid zijn beide bedoelt om het laden van een web-app en de executie er van te meten. Het gaat hier om bijvoorbeeld in het Google geval te meten hoeveel requests wat er op gehaald werd welke tijd er tussen request en respose zat, hoelang de download duurde welke snelheid er mee gedownload werd hoelang de verwerking en de rendering duurde.
Het doel van beide API's is om ontwikkelaars de mogelijkheid te geven te zien hoe hun applicatie zich gedraagt waarom dingen langzamer gaan dan verwacht en waar er bijvoorbeeld snelheidswinst te behalen valt.

Met een standaard API kun je je voorstellen dat er een plugin zal komen voor de bekende IDE's om je applicatie te profilen in de verschillende browsers en uit te vinden waar in je code de verschillende browsers het het moeilijkst hebben. Ook voor de browser bouwers zelf kan dit heel erg handig zijn en kun je bijvoorbeeld verwachten dat Google en MS applicaties zullen gaan schrijven om de zwakheden van elkaars browsers aan te tonen wat er weer toe zal leiden dat ze beide juist de zwakke delen zullen gaan verbeteren wat ons allemaal weer ten goede zal komen uiteindelijk.

Het is net als de pagina's die de web standaarden testen in de verschillende browsers. Pas toen het echt makkelijk aan te tonen was dat bepaalde browsers (IE) zich zeer slecht aan de standaarden hielden werd dit op de agenda gezet omdat mensen dit als reden opvoerde om juist deze browser niet meer te gebruiken.

[Kawaii]

Naast Javascript is de afhandeling van bijvoorbeeld CSS belangrijk, en veel dingen uit de (nog steeds niet volledig of officiele) HTML5 specificaties die met name in de toekomst een grotere rol gaan spelen.
Momenteel zijn er wel een aantal testen die men gebruikt om een beeld te krijgen om browsers onderling te vergelijken, een van de uitgebreidere is Peacekeeper

[shaloca]

Leuke test, maar is weiger te geloven dat er zoveel snelheid verschil zit ussen de browsers, misschien op bepaalde specifieke onderdelen, maar over het geheel.
Als ik dit moet geloven moet ik Opera maar eens installeren naast IE, firefox en Chrome die ik nu op de computer heb.

[SpaceK33z]

Nou, Internet Explorer 8 is anders extreem sloom, zelfs in vergelijking met Firefox. Ik heb beide browsers open staan (helaas moet ik soms IE gebruiken voor Sharepoint) en merk dat IE8 echt sloom is.

[Mesjefskie]

uhm... Het artikel gaat over het feit dat de w3c een werkgroep heeft opgericht die gaat proberem een methode te ontwikkelen om prestaties van browsers objectief te kunnen meten. Vervolgens wordt vermeld dat Google en Microsoft zitting hebben genomen in deze werkgroep. Hierna worden techieken besproken die deze twee bedrijven gebruiken om webontwikkelaars te helpen de prestaties van de browsers van de hierboven genoemde bedrijven te bepalen. Microsoft gebruikt de webtimings-api, Google de WebKit -engine.

Waar past Apple volgens jou in dit verhaal? Of moet er in ieder artikel waarin er op de een of andere manier wordt gerefereerd aan iets wat zijdelings met Apple te maken zou kunnen hebben, dit vermeld moeten worden? Wat is tweakers.net? Een PR/reclamesite voor Apple?

[YopY]

Waar past Apple volgens jou in dit verhaal? Of moet er in ieder artikel waarin er op de een of andere manier wordt gerefereerd aan iets wat zijdelings met Apple te maken zou kunnen hebben, dit vermeld moeten worden? Wat is tweakers.net? Een PR/reclamesite voor Apple?

Apple is de bouwer van de WebKit render engine - mcdronkz vindt het apart dat daar geen melding van gemaakt wordt, en dat volgens hem blijkbaar de Webkit rendering engine aan Google toegekend wordt.

Echter, zoals ik het lees heeft Google slechts het timing framework ontwikkeld en aan Webkit toegevoegd.

[humbug]

En webkit is een fork van de konquerer engine. Zullen we die er dan ook altijd bijhalen

[watercoolertje]

Apple heeft erhelemaal niks mee te maken...

"Google heeft een soortgelijk timing-framework ingebouwd in de WebKit-engine die voor Chrome wordt gebruikt."

Oftewel Google heeft iets gebouwd, DAAR gaat het om, dat er toevallig voor WebKit is maakt helemaal niet uit, Apple heeft dus niks met dit bericht te maken, ookal hebben ze misschien wel een webtimings-api, ze zitten niet in de werkgroep waar het om gaat, dus is het irrelevantie of hun wel of geen webtimings-api hebben (net als het niet boeiend is om te melden waar webkit vandaan komt, wat overigens ook niet ENKEL Apple is maar ook een werkgroep)...

[Reactie gewijzigd door watercoolertje op 27 juli 2024 10:56]

[veltnet]

Webkit komt toch van Konqueror (de KDE webbrowser). Apple heeft deze later overgenomen voor Safari.

[Relief2009]

Volgens mij was het sarcasme...

[Pixeltje]

Dat heeft in mijn ogen niet zoveel met stijl te maken: kennelijk heeft Apple nog geen timingsmechanisme geïmplementeerd, en Google wel... Dat is ten slotte ook waar het bericht om gaat, het is geen opsomming van webkit-based browsers.

[Anoniem: 341936]

Waarschijnlijk is de reden dat Apple niet genoemd wordt omdat Apple waarschijnlijk niet in de werkgroep zit (ik kan dit niet nakijken op de website van W3C omdat je een inlogcode ofzo moet hebben), en er is dus ook geen reden om Apple erbij te halen. Dat Google toevallig webkit gebruikt is wat mij betreft ook geen reden aangezien het hier volgens mij common knowledge is dat Apple webkit heeft gemaakt.

[Pixeltje]

I beg to differ. In andere nieuwsberichten worden merken en fabrikanten met gelijkwaardige functies in hun producten ook weleens achterwege gelaten, dat heeft niets met censuur of onderdrukking te maken lijkt me. Het wordt behoorlijk vermoeiend om steeds alle fabrikanten op te sommen die ook meedoen aan het onderwerp van het artikel. Als Apple wel genoemd wordt ontstaan er ook discussies. Het zou fijn zijn als we elkaar hier wat meer licht in de ogen gunnen.

[Little Penguin]

Blijkbaar stelt deze - overigens uitmuntende - website alles in het werk om het A-woord van de voorpagina te kunnen verbannen om te verhinderen dat discussies als deze zullen plaatsvinden.

Maar als je dat moet doen, dan blijf je bezig. Waarom moet Apple overal bijgesleept worden? Want WebKit is weer voorgeborduurd op KHTML en dan moet dat ook genoemd worden en JavaScript is een taal die door Brendan Eich van Netscape ontwikkeld is en Brendan werkt tegenwoordig bij Mozilla en dan moeten we dat ook nog even noemen.

Zo blijf je dus bezig...

In dit nieuwsbericht gaat het om het oprichten van de werkgroep en worden de producten van de voorzitters van die groep nog even meegenomen ter illustratie.

[Reactie gewijzigd door Little Penguin op 27 juli 2024 10:56]

[BlakHawk]

Lees eens terug, juist de bewering dat het van Apple vandaan zou komen is irrelevant...

[Tarabass]

Ik zie een grote donkere wolk hangen. Waarom? IE9 komt waarschijnlijk begin volgend jaar uit, de beta volgende maand. De api waar het om gaat is al geïmplementeerd in IE9. Komen de heren er dus niet uit, dan zal MS (net zoals wat is het, 15 jaar geleden, met het ontwikkelen van w3c) gewoon op eigen voet doorwandelen met hun api. Google zal nooit de volledige api zoals hij nu is accepteren en zijn eigen vinger in de pap willen houden. Resultaat zal zijn, of IE9 met een api die net geen standaard is of een standaard die pas in de volgende browser van MS geïmplementeerd gaat worden..

[Little Penguin]

Ik zie een grote donkere wolk hangen.

Op het moment dat Microsoft voor deze api netjes een ms-prefix gebruikt, is er niets aan de hand. Je kunt natuurlijk standaard er vanuit gaan dat Microsoft expres de boel dwars wilt zitten, maar sinds IE8 lijkt het er meer op dat men nu eens wel samen gaat werken met het W3C - iets dat ze toch al deden, maar dan alleen als het hun uit kwam.

window.msPerformance.timing
window.msPerformance.timingMeasures
window.msPerformance.navigation

Bron: http://blogs.msdn.com/b/i...web-page-performance.aspx

Zie daar, de "ms"-prefix, die in dit geval staat voor Microsoft en niet milliseconds oid. Dus ja in MSIE9 zit een afwijkende standaard, maar in MSIE10 komt dus wel de juiste standaard. Via Javascrip-sniffing kun je uitstekend controleren welke API er gebruikt wordt en dan de bewuste sub-properties uitlezen, hulpmiddelen als bijvoorbeeld jQuery kunnen dan weer gebruikt worden om de vershillen weg te masseren en als je dat niet wilt gebruiken zul je het zelf moeten doen als web-ontwikkelaar...

[Anoniem: 80466]

Op het moment dat Microsoft voor deze api netjes een ms-prefix gebruikt, is er niets aan de hand

Dat is het geval.

[Tsjilp]

En wat Microsoft volgens jou moeten doen dan? Wachten tot de heren bij het w3c eruit zijn en dan pas ie9 uitbrengen?

[Anoniem: 80466]

De api waar het om gaat is al geïmplementeerd in IE9.

De webtimings spec die IE9 implementeert bestaat ook al.
http://dev.w3.org/2006/webapi/WebTiming/
Het is echter nog een product dat uitbreiding/aanpassing behoeft

[Fuzzillogic]

De W3C zou zich m.i. een beter bezig kunnen houden met het opstellen van een specificatie voor een bruikbare mark-up voor webapplicaties, dus met normale, fatsoenlijke GUI-widgets. Een bruikbare GUI maken met HTML is gewoon ruk, qua usability en qua ontwikkeling, omdat HTML daar gewoon nooit voor bedoeld is. Wat mij betreft is HTML5 dan ook al een behoorlijke flater op dat gebied.

Daarnaast zou het ze eens sieren om te kijken hoe ze van javascript, een verschrikkelijke taal imo, eens kunnen aanvullen met een strong-typed taal met een uitgebreide, krachtige standaard runtime. Dat ze eens een voorbeeld nemen aan .NET/C# of Java of Android of Qt of Cocoa/Objecte C of JavaFX of... iets fatsoenlijks iig!

[mcdronkz]

Als je, net als veel anderen die voor het Apple-platform ontwikkelen, de voorkeur geeft aan Objective-C, dan heb ik een interessante link voor je:

http://cappuccino.org/

Deze getalenteerde ontwikkelaars hebben "Objective-J" gerealiseerd, een op JavaScript gebaseerde implementatie van Objective-C. Tevens hebben ze grote delen van het Cocoa framework naar Objective-J geport. Een prachtig initiatief, als je het mij vraagt.

[johnbetonschaar]

Misschien niet precies in de vorm waarin jij het zou willen zien, maar ook hier houdt W3C zich mee bezig:

http://www.w3.org/2008/webapps/

Het gaat dan om web-standaarden waarmee bedrijven zelf hun eigen markup elementen en widgets kunnen definieren en distribueren, en allerlei aanverwante technieken die je nodig hebt om web-applicaties te maken. Een complete W3C GUI toolkit zal er nooit komen, ten eerste omdat het niet de doelstelling van het W3C is om zelf software te bouwen en verspreiden, en ten tweede omdat waarschijnlijk niemand het zou gebruiken, elk bedrijf en elke website wil toch zijn UI een eigen smoel geven.

Wat betreft JavaScript: dat is een ECMA standaard waar W3C helemaal niks mee te maken heeft. Los daarvan denk ik dat het een heel erg slecht idee is om JavaScript te vervangen door striktere talen die op Java of C# lijken, omdat bij dat soort talen standaard ook een berg overhead en complexiteit meekomt die je voor simpele scriptjes helemaal niet wilt hebben. JavaScript is niet geweldig inderdaad, maar het is wel ontzettend makkelijk te embedden in HTML, snel en makkelijk te schrijven, en het bevat praktisch niks meer dan strikt noodzakelijk, en dat is ook een voordeel.

[Anoniem: 183324]

Ik vraag mij af is het sowieso een taak voor de W3C is om een benchmark te creeren voor browser performance. De browser is een applicatie en hangt af van de OS, hardware etc. Als je een op standaards gebaseerde web applicatie maakt, zou het op allee browsers moeten draaien, onafhakelijk van realtieve prestaties.

Dus ik ben met je eens dat ze beter hun tijd aan het verbeteren van de standaarden kunnen besteden.

[Anoniem: 178824]

Een standaard om de werksnelheid te meten... en de recommendation komt in oktober 2011.... humor

[Blokker_1999]

naar W3C termen is een jaar zeer snel. Kijk maar eens hoe lang HTML5 of CSS3 doen over hun standarisatie.

[Anoniem: 178824]

Hierbij wordt een opmaak bedacht. Browserbouwers moeten deze code opnemen zodat deze juist gerenderd wordt. Dat is aanzienlijk ingewikkelder dan het vaststellen hoe er gemeten moet worden om de laad/uitvoeringstijd van een een bepaalde script in een bepaalde browser duurt.

[Anoniem: 80466]

In W3C is een "recommendation" de finale standaard.

Ofwel dan is de standaard dus af en goedgekeurd.
14 maanden voor het complete standaardisatie proces is in standaardisatiewereld erg snel.
Dan moet je al voortborduren op bestaande zaken zoals hier ook deels de bedoeling is.

[Cronax]

Zoiets heb je niet even geklaart in een weekje hoor

[Anoniem: 178824]

Inderdaad. Met een budget van miljarden duurt het vaststellen van enkele criteria toch zeker enkele minuten....

Het tijdsbestek van enkele maanden komt voort uit onderzoek hoe je bepaalde resultaten moet interpreteren en verkopen aan de massa. Het gaat hier niet om het uitvinden van een nieuw product maar om het vastleggen van een methode om bestaande prestaties te meten.

Als je dit wilt automatiseren in een API o.i.d. is prima maar ook dat hoeft niet maanden te duren.

Kortom: it aint usefull, its marketing.

[OddesE]

Ik denk dat dit artikel wellicht wat verwarrend is en dat men eigenlijk niet per se de prestaties van de browser wil meten maar van de website die draait op de browser... Ik denk aan de tijd die de browser besteed aan het renderen, toepassen van styling, uitvoeren van script code, ophalen van resources (afbeeldingen), AJAX calls etc.

Als dat zo is dan is het zeker wel nuttig want dan kunnen web developers, behalve zien dat hun pagina traag laadt, ook er achter komen *waarom* dat zo is en hopelijk verbeteren. Een soort profiler voor webapps dus. In dat geval dus zeker niet alleen marketing maar zeker wel heel nuttig.

[humbug]

Profiling zit standaard in java en .net. sites die daarmee gebouwd zijn hebben dit niet nodig. En andere ontwikkelomgevingen zullen ook wel wat hebben. Als profiling het doel is voegt dit weinig toe. Wel maakt het de verschillen tussen browsers inzichtelijk en kun je bijvoorbeeld je monitoring software een event laten genereren als je site traag wordt.

[Anoniem: 84013]

Voor server-side prestaties, ok. Maar de client-side prestaties kun je daarmee niet vastleggen. Daar biedt een standaard als deze juist weer mogelijkheden voor.