Wenn das Javascript lahmt, gibt es viele Ansätze um die Performance zu verbessern – smarte Schleifen, Scope-Optimierung, Closure-Diät und kürzere Ketten beim Objektzugriff (foo.bar
ist flotter als foo.bar.blubb.blah
). Dass all das zwar Geschwindigkeit bringt, jedoch in 99% aller Fälle nicht das Problem ist, an dem man arbeiten sollte, sollte eigentlich das in aller Länge un Breite ausformulierte Thema dieses Beitrags werden, doch dann flatterte dieses schöne Video vorbei. Hier referieren Nicholas Zakas, Stoyan Stefanov, Ross Harmes, Julien Lecomte und Matt Sweeney über das, was sie in diesem schönen Buch geschrieben haben – High Performance Javascript eben.
In dem Video werden viele Wege der JS-Optimierung beschrieben, aber die besten Zahlen führt eindeutig Stoyan Stefanov in seinem Vortag über das DOM zu Felde: bei unbedachter Arbeit am DOM-Tree hat man selbst im besten Browser Glück, wenn man sein Script nur 20× so langsam macht, wie es sein könnte. Das heißt: sofern man Javascript im Browser verwendet und damit Animationen und ähnliches umsetzt (was wohl so um die 99% aller Anwendungsfälle ausmacht), ist der Flaschenhals, um den man sich vorrangig kümmern sollte, das DOM.
Der geschwindigkeitsbringende Umgang mit dem DOM ist dabei ganz einfach, sofern man zwei Regeln befolgt:
- So wenige DOM-Operationen jedweder Art durchführen wie möglich
- Fleißig
documentFragment
verwenden (Details)
Stefanov hat noch 8 weitere Regeln im Angebot (siehe Buch und Video) doch allein mit diesen beiden kann man die meisten Scripts schon erheblich beschleunigen. Wenn man also auf der Fahndung nach Javascript-Performance ist, sollte man im DOM anfangen zu suchen. Für Otto Normalwebworker, der nur hin und wieder ein paar Animationen und Ajax-Requests zu basteln hat, sind all die anderen Optimierungen zwar auch interessant (deshalb Video schauen und Buch lesen!), aber wenn das Script lahmt, liegt das Problem doch oftmals woanders.
Ebenfalls zum Thema und überaus ansehenswert, falls noch unbekannt: Speed Up Your JavaScript, ebenfalls von und mit Nicholas Zakas.
Kommentare (4)
Sebastian Gebhard ¶
22. April 2010, 13:51 Uhr
Hättest du den neuen FB "I like"-Button in deinem Blog - jetzt hätte ich ihn zum ersten mal benutzt. So geht's eben ab in die Bookmarks, damit ich mir das Video gönnen kann, wenn ich mehr Zeit hab.
Klingt jedenfalls spannend..
Tobias ¶
22. April 2010, 15:39 Uhr
Danke für den Beitrag. Bei Youtube gibt es noch weitere gute Vorträge:
Speed Up Your JavaScript
http://www.youtube.com/watch?v=mHtdZgou0qU
Best Practices in Javascript Library Design
http://www.youtube.com/watch?v=0LKDImgRfrg
Upcoming Changes to the JavaScript Language
http://www.youtube.com/watch?v=-yDS1eGfuWQ
Debugging and Testing the Web with Firebug
http://www.youtube.com/watch?v=7p24bC8ZR3U
Faster HTML and CSS: Layout Engine Internals for Web Developers
http://www.youtube.com/watch?v=a2_6bGNZ7bA
JavaScript: The Good Parts
http://www.youtube.com/watch?v=hQVTIJBZook
High Performance Web Sites and YSlow
http://www.youtube.com/watch?v=BTHvs3V8DBA
antpaw ¶
22. April 2010, 18:45 Uhr
Sebastian Gebhard:
performance und like buttons:
http://developers.facebook.com/docs/reference/plugins/like
ein like button = ca 15 http requests, sollte man fast mit flash machen :)
Siegfried ¶
24. April 2010, 14:44 Uhr
Zum Artikel: Ist gut, das mal explizit irgendwo lesen zu können. Immerhin muss bei jeder Verwendung von document.blablubb der ganze Dokumentenbaum wieder und wieder durchgenudelt werden. Da ist die Idee, sich mit documentFragment einen "pointer" auf ein Teildokument zu halten sehr sinnvoll. Meist beziehen sich Animationsscripte ja auf einen kleinen teil des Dokuments.
Button: Die Idee ist eigentlich gar nicht so schlecht. Aber wozu einen extra "title"? Ist doch schon wieder mal doppelt gemoppelt. Das Meiste davon gibt's bereits. Der Button ist in der Form also eigentlich weitgehend überflüssig. Eine sauber gecodete Seite enthält alle diese Informationen auch ohne Facebook. Nur das mit dem assoziierten Bild ist neu. Diesen Part könnte man ja übernehmen. Aber als Bilder sind dazu eher diese "badges" im Format 80x15 gängig, und keine 50x50 Bilder. Für rss gibt's den Link zu einem assoziierten Bild (Logo o.Ä.) bereits. Fehlt nur eine standardisierte Version, das auch in html einzubauen.