Wieso man Javascript nicht im Head lädt (und im Footer besser auch nicht)

Ich kann mich noch erinnern als Anfang der 90er Javascript noch ein außerirdisches Mysterium war, und zwei Zeilen Inline-Javascript das höchste der Gefühle. Erschwerend kam hinzu das ein gewisser Browser-Hersteller durchaus eigene Vorstellungen davon hatte, wie eine Skriptsprache was zu machen hat (ich erinnere nur an die verzweifelten Versuche VBScript zu etablieren). Heute tickt die weiterlesen

6 Kommentare

  • „[…] Ich kann mich noch erinnern als Anfang der 90er Javascript noch ein außerirdisches Mysterium […]“ … Anfang der 90er?

    Javascript ist erst 1995 erschienen, und im Internet tatsächlich eingesetzt wurde Javascript ab Ende 1996… vielleicht mal die Gedächtnisdatenbank überprüfen? :)

  • @Jan

    Das kann aber auch nach hinten losgehen. Denn alles JavaScript, das hereinfliegt muss nicht nur geladen werden, sondern es wird, sobald es komplett ist, vom Browser sofort interpretiert und kompiliert. je größer der JS Code en bloq ist, desto länger blockiert der dann am Stück.

    Ein gutes Testobjekt dafür ist z.B. ein Custom-Build des Dojo Toolkit, in das Du mal alle Form-Widgets reinbackst. Das wird ziemlich groß und bringt für einen kurzen Moment selbst einen Core i7 zum stottern.

    Hast Du mehrere kleine Dateien, dann blockiert er entsprechend auch nur Häppchenweise, und dauert jeder dieser Happen weniger als 50ms, dann merkt der User erst gar nichts davon. Das Interface bleibt flüssig:

    http://vimeo.com/16241085

    Ebenfalls steigt der akkumulierte Gesamtdurchsatz, sobald Du mehrere Verbindungen parallel öffnen kannst, analog zu der Technik, die Download-Manager an den Tag legen um die Internetleitung auf Anschlag zu bekommen:

    http://calendar.perfplanet.com/2010/thoughts-on-performance/

    Am besten ist also eine Kombination: unabdingbares JavaScript auf eine Handvoll Dateien zusammengruppieren, und diese dann parallel laden lassen. Und alles was erst später notwendig ist auch erst bei onload hinterherladen, wenn die Leitung wieder frei ist, der User sich aber noch orientiert.

  • Ein wenig kann man dem Problem aber auch entgegenwirken, indem man das gesamte JavaScript zu einer Datei zusammenfassen lässt und dann auch noch mit GZIP behandelt.

    Da das ganze unter Drupal nicht ganz trivial ist, habe ich letztes Jahr einen Blogbeitrag zu dem Thema geschrieben.

    http://blog-das-oertchen.de/blog/2010/09/28/drupal-sinnvolle-optimierungen-teil-1

    Eventuell sollte ich meine Lösung aber trotzdem noch mit der head.js kombinieren, da derzeit eine große Datei im Head-Bereich geladen wird und ein Nachladen (zumindest bei meinen Projekten) wohl besser wäre.

  • […] JavaScript hat seit den 90er Jahren eine erstaunliche Wandlung durchgemacht. Wurde es zunächst nur sehr sehr sparsam eingesetzt, auch weil die damaligen Browser so ihre Schwierigkeiten damit hatten, so gehört JavaSript heute in einer Vielzahl einfach dazu, wenn man über moderne Webseiten spricht. Für die Website-Optimierung ergibt sich daraus eine interessante Fragestellung: An welcher Stelle sollte man die JavaScripte laden lassen? Guido Mühlwitz hat sich mit dieser Frage auseinander gesetzt. […]

  • Kleine Randnotiz: Aktuelle Browser, inklusive des IE8, sind im Unterschied zu früher mittlerweile in der Lage, mehrere, im Quelltext nachfolgende Scripte parallel zu einem aktuell in der Bearbeitung befindlichen Script vorzuladen, auch wenn der Rendervorgang nach wie vor an der aktuellen Stelle hängen bleibt. Das hat dann immerhin den Vorteil, dass in die nachfolgenden Blockiervorgänge (pro Script einer) nicht mehr die Ladezeit hineinfällt, sondern nur noch die reine Code-Aufbereitung und -Ausführungszeit.

    http://www.stevesouders.com/blog/2010/02/07/browser-script-loading-roundup/

    Zum Aufmöbeln alter und althergebracht aufgebauter Seiten verweise ich auf noch ein weiteres, brandneues Framework, das in der Lage ist, jene mit wenigen Handgriffen am Code (Änderungen an den src und type Attributen der Script-Tags) komplett zu „entblockieren“:

    ControlJS
    http://stevesouders.com/controljs/

Schreibe einen Kommentar