auch wenns weh tut

Lange habe ich mich gewehrt, den wirklich einfachsten Performance-Trick einzubauen. Jetzt habe ich mich getraut – ich habe meine Javascripte ans Seitenende verbannt. Das hat für eine komplette Site ungefähr 23 Sekunden gedauert. Der gefühlte Geschwindigkeitsgewinn ist unfassbar. Die Seite wird in einem Bruchteil der zuvor benötigten Zeit angezeigt.

Der Geschwindigkeitszuwachs ist aber rein psychischer Natur. Die Seite ist keinesfalls schneller fertiggeladen, sie wird lediglich eher angezeigt. In den allermeisten Fällen sollte das aber auch völlig ausreichen.

Veröffentlicht in:  on 31. Januar 2009 at 22:47 Kommentare (1)
Tags: ,

zusammenhalten

Sizzle, die neue CSS-Selector-Engine von John Reisig, dem Vater von jQuery, ist für mich ganz klar das neue jQuery-Herz – und ich freue mich drauf. Gerade las ich hier, dass auch Dojo und Prototype mit dem Gedanken spielen, Sizzle einzusetzen. Damit dürften sich die Javascript-Frameworks geschwindigkeitsmäßig und im Funktionsumfang annähern.

Wenn jetzt noch die Browserhersteller …

Veröffentlicht in:  on 4. Dezember 2008 at 00:29 Kommentar schreiben
Tags: , ,

Javascript nachladen

Viele Seiten setzen inzwischen ziemlich viel Javascript ein. Das kann dazu führen, dass die Seite länger braucht, um angezeigt zu werden. Zum einen, weil eine relativ große Datenmenge heruntergeladen werden muss (leitungsabhängig), zum Anderen, weil das gesamte Script auch noch interpretiert werden muss (hardware- und browserabhängig).

Ich habe begonnen, den Großteil meiner Scripte erst nachzuladen, wenn die Seite fertig gerendert ist. Zum Glück kommt inzwischen oft jQuery und Google-maps zum Einsatz, so dass sich anbietet, den google-Ajax-Loader zu verwenden.

… und die eigenen Scripte?

Beim konsequenten Einsatz von jQuery sollten die eigenen Scripte eigentlich vernachlässigbar kurz sein ;P.
Kommt dennoch mal mehr Code zum Einsatz, könnte man eigentlich auch mehr nachladen. Aktuell sind das bei uns zum Beispiel das Adserverscript, das Statistikscript und unsere eigenen Scripte. Hier wiederum bietet sich an, nur ein winziges Javascript gleich im Seitenkopf einzubetten:

var loadAnyScript = function(url){
    var head = document.getElementsByTagName("head")[0];
    var script = document.createElement("script");
    script.src = url;
    script.type = "text/javascript";
    head.appendChild(script);
    script.onload = function(){
        head.removeChild(script);
    }
};

Für mehrere Scripte bietet sich an, das Ganze noch ein Wenig zu pimpen:

var speedingUpJs = {
    scripts: ["/sript1.js", "script2.js", "http://url1.de/script.js"],
    init: function() {
        for each (script in this.scripts)
            this.loadAnyScript(script);

        // die restliche Initialisierung
    },
    loadAnyScript: function(url){
        var head = document.getElementsByTagName("head")[0];
        var script = document.createElement("script");
        script.src = url;
        script.type = "text/javascript";
        head.appendChild(script);
        script.onload = function(){
            head.removeChild(script);
        }
    }
};

Laut AJAX-API lässt sich sogar das google-Script nachladen.

PS: Im Script habe ich for each als Seitenhieb untergebracht. Der IE kanns nämlich nicht.
PPS: Im gesamten Script kommt kein jQuery vor, weil wir das Framwork ja erst nachladen wollen.

Veröffentlicht in:  on 30. November 2008 at 23:05 Kommentar schreiben
Tags: , ,

Slideshow in schön

Seit ich mit jQuery code, weiß ich nicht mehr so genau, wozu es überhaupt noch flash gibt. Der s3Slider ist wieder so ein Beispiel für eine Slideshow, wie sie sonst nur in flash realisert würde.
Schön.

Veröffentlicht in:  on 28. November 2008 at 22:00 Kommentar schreiben
Tags: ,

MacBook, Javascript und Firefox

Die Ereignisse überschlagen sich. Beinahe hätte ich Steve Jobs Keynote verpasst, weil ich mir gerade Chris Heilmanns „Maintainable Javascript“ Tutorial angesehen hatte.
Hier beschreibt er, wie man möglichst verhindert, dass Scripte schon nach wenigen Monaten Einsatz selbst für den damalien Urheber nicht mehr wartbar sind. Wie man Javascript in seinen Seiten richtig einsetzt und wie man mit Javascript das Aussehen von HTML-Seiten richtig verändert. Dies erscheint mir so wichtig, dass ich es hier nochmals zitieren möchte:
Natürlich kann man mit Javascript und
Element.style.height = neuerWert;
das Aussehen einzelner Elemente verändern. jQuery drängt sich hier mit
Element.css({ height: neuerWert });
geradezu auf. Viel besser jedoch ist in jQuery
Element.removeClass(alteKlasse);
und
Element.addClass(neueKlasse);.
In normalem Javascript löst das
Element.className = „neueKlasse“;.
Das Aussehen wird hier weiterhin über das Stylesheet und css-Klassen, nicht über ein viel schwerer wartbares Script bestimmt.

Diese Zeilen schreibe ich übrigens mit dem Wunsch, möglichst bald das neue MacBook zu besitzen und im neuen Firefox 3.1 beta1, bei dem sich nicht wahnsinnig vie geändert hat – bis auf den wirklich spürbaren Geschwindigkeitsgewinn.
Wow. Damit ist er gefühlt nahezu gleichauf mit Iron, dem entgoogelten Chrome.

Veröffentlicht in:  on 15. Oktober 2008 at 22:28 Kommentar schreiben
Tags: , , , ,

use frameworks

Lisa hat eine wöchentliche Fotostunde eingerichtet und verbietet gleich in der ersten Stunde, die Default-Einstellungen zu benutzen. Dasselbe verbietet Darkmotion bei der Benutzung von Filtern. Zeit für mich, auch irgendwas zu postulieren.

Benutze Frameworks

Bei Stylesheets sind sie umstritten, bei Javascript ein Muss. Wenn Ihr irgendwas mit Javascript machen wollt nehmt ein Framework. Oder als Verbot formuliert: sucht nicht für jedes Problem ein Script bei Google. Seit ich jQuery benutze bastele ich Funktionen, die ohne Framework undenkbar waren. Dazu kommt, dass es für nahezu jede Anforderung schon ein passendes Plugin gibt. Ein angenehmer Nebeneffekt ist, dass man den Internet-Explorer weniger hasst, weil man nicht mehr jedes Script nochmal schreiben muss.

Veröffentlicht in:  on 28. August 2008 at 15:56 Kommentar schreiben
Tags: ,

alle wollen schneller

Wenige Stunden nachdem ich das Post über die neue Javascript-Engine für den Firefox gelesen habe, die natürlich viel viel viel schneller als alles Bisherige ist, legen die Redmonder nach und beschreiben, warum ihr Browser der schnellste und produktivste sein wird. Aufgeschreckt durch so viel Ehrgeiz habe ich schnell für die Nachwelt einen Snapshot angefertigt. Hier also der Stand vom 27.8.2008, eine Selector-Speed-Messung mit gängigen Frameworks im Firefox3 und IE8beta.
Firefox3:

Firefox3

Firefox3

IE8beta:

IE8-Performance

IE8-Performance

Abgesehen davon, dass die Dojo/Unterstützung für den IE8 noch nicht ganz ausgereift ist, wird ganz schnell deutlich, dass der Firefox die Tests zur Zeit deutlich schneller absolviert, als sein Microsoft-Konkurrent. Da existiert Nachholbedarf.

Bremse Design

Aus dem IE-Post wird aber auch deutlich, dass, gemessen am Gesamtaufwand eine Webseite anzuzeigen, Javascript ein eher unbedeutender Posten zukommt, verglichen mit CSS. Wow. Seit Tagen beschäftige ich mich damit, zu messen, wie unterschiedliches Markup die Rendergeschwindigkeit beeinflusst, bin aber noch zu keinem vorzeigbaren Ergebnis gekommen. Der Selector-Speed-Test erscheint mir ungeeignet, weil zumindest mein geliebtes jQuery beim Zugriff auf DOM-Knoten nicht immer die getElement-Methode, sondern häufig auch RegEx benutzt, was in Zukunft übrigens viel viel viel schneller vor sich gehen wird, wenn John Reisigs neue Selector-Engine Sizzle zum Einsatz kommen wird.
Aber das ist schonwieder ein ganz anderer Post….

via

Veröffentlicht in:  on 27. August 2008 at 10:22 Kommentar schreiben
Tags: , , ,

css, und wie man richtig benamst

Hier soll es ganz kurz mal um sinnvolle Benamung von Klassen und IDs gehen. Hintergrund dieser Betrachtung ist, dass Webseiten heute meistens nicht aus einer Datei bestehen, die man von vorne bis hinten durchlesen kann, sondern aus vielen vielen kleinen Schnipseln, die zu tausenden in ein CMS kopiert werden. Darum ist es bei Stylesheets, genau, wie in Javascript, in php und in all den anderen Sprachen, die wir hier noch behandeln wollen sehr sehr wichtig, wie man etwas nennt:

Sprechend klassifizieren

Wie schon hier beschrieben, beschreibt eine css-Klasse nicht, wie etwas aussieht, sondern was es ist. Darüber hinaus sollten Klassen von vornherein so eindeutig sein, dass man nicht schon während des Entwurfs seine Konvention ändern muss:
Falsch:
h2.title
Besser:
h2.teaser-listing
Denn es ist absehbar, dass im restlichen Dokument noch weitere Titel folgen werden.

Im vorigen css-Post habe ich schon beschrieben, wie man grid und Typographie, aber natürlich auch Farbgebung und Linkverhalten voneinander trennen kann, das erspart übrigens auch, ständig neue Deklarationen für immer dasselbe erfinden zu müssen. Angenommen, wir haben eine vertikal dreigeteilte Seite (Header, Body, Footer), die horizontal zweigeteilt ist. Dann wäre es doch sinnvoll, die Elemente so zu benamsen und zu deklarieren:
.column-left {
    float: left;
}
.column-right {
    float: right;
}
#header .column-left {
    margin: 0 5px;
}
#header .column-right {
    margin: 0;
}
#content .column-left {
    border: 1px solid;
}
#content .column-right {
    background: #f2f2f2;
}
#footer .column-left {
    background: #cccccc;
}
#footer .column-right {
    background: #f2f2f2;
}

Spare IDs

Eine ID sollte im html-Dokument etwas besonderes sein. Es sollte eine Ehre sein, eine ID zu bekommen. Hier ist es sinnvoll, xhtml einfach mal zu xml zu abstrahieren und zu überlegen, welches Element einer Seite so wichtig ist, dass ich ein eigenes xml-Element dafür deklarieren würde. Da IDs also nur höchst selten anzutreffen sind, ist es umso wichtiger, aber auch einfacher, sie sprechend zu benennen. Einzige Ausnahme sind hier Elemente, auf die mit Javascript über document.getElementById zugegriffen werden muss. Wie sich das vermeiden lässt, soll ein nächster Post erklären.

Veröffentlicht in:  on 21. August 2008 at 11:00 Kommentar schreiben
Tags: , , , ,