Posts in Category ‘It’s all about speed!’

Websitegeschwindigkeit über UMTS/EDGE testen

Viele Webdeveloper kennen das Problem sicherlich: Man sitzt zu Hause vor der dicken Leitung mit 25, 50 oder gar 100 MBit und baut z.B. eine mobile Version einer Website. Schwer vorstellbar, wie da die Ladezeiten im wirklichen Leben auf mobilen Endgeräten aussehen. Und das komplette Kontingent seiner Daten’flatrate’ will man ja auch nicht mit Tests aufbrauchen.

Abhilfe kommt von Apple. Im neuen XCode 4.1 (kostenlos) für Max OS X Lion (10.7) findet sich, versteckt unter /Programme/Dienstprogramme (bei manchen auch unter /Developer/Applications/Utilities) ein Ordner Namens Network Link Conditioner.

Klickt man die Prefpane-Datei doppelt, die sich darin befindet, installiert sich ein neuer Eintrag in den Systemeinstellungen, über den man verschiedenste Zugänge und Leitungsqualitäten simulieren kann. Apple hat bereits diverse Profile angelegt, eigene Konfigurationen kann man problemlos hinzufügen. Und dann kann man feststellen, dass beispielsweise diese Seite über VDSL50 in knapp zwei Sekunden lädt, während sie über gutes 3G-Netz ca. 10 mal so lange braucht.

Es wäre schön, wenn Apple dieses Utility einzeln zum Download anbieten oder direkt mit Lion ausliefern würde, derzeit bleibt einem nur der 3GB große XCode-Download. Nur dafür lohnt sich das sicherlich nicht, alle, die XCode sowieso installiert haben, bekommen aber ein nützliches kleines Helferlein für die tägliche Arbeit an die Hand.

via Matt Gemell

Jeder darf mal: .htaccess-Bullshit

Geschwindigkeit ist ja der neue Backlink und jeder meint, da seinen Senf dazugeben zu müssen. Und egal wie blödsinnig die Umsetzung ist, es wird sich immer wer finden, der’s geil findet.

Zwei Sachen dazu:
Das hat im .htaccess nichts verloren. Über Performance schreiben und dann das .htaccess-File zumüllen ist wie bei 280 auf der linken Spur über den hohen Benzinpreis jammern. Wer Zugriff auf seine Apache-Konfiguration hat sollte das dort unterbringen. Immer.
Hartkodierte Datumsangaben, die, vom heutigen Standpunkt aus, weit in der Zukunft liegen, sind eine ganz schlechte Idee. Ist ja nicht so, dass wir das nicht erst hatten. mod_expires bringt da ein viel einfacheres Mittel, um genau das Problem zu vermeiden.

Finger raus aus der Keksdose!

Eine sehr einfache Methode, Bandbreite zu sparen und Daten schneller auszuliefern ist, sie ohne Cookies zu senden.

Google sagt:

Serve static content from a cookieless domain

Liegen dynamische Daten und Bilder, Stylesheets und Javascript-Dateien auf der gleichen Domain sendet der Browser bei jeder Anfrage die Cookies, die er für diese Domain gespeichert hat, mit. Was absolut unnötig ist, denn die wichtigste Eigenschaft von statischem Content ist, dass er genau das ist: Statisch.

Also raus mit den Cookies. Einfachste Lösung: Eine Subdomain anlegen, z.B. static.domain.de, als ServerAlias in der Apache-Konfiguration hinzufügen und alle Bilder, Javascripts und Stylesheets über diese URL adressieren. Alternativ kann man es machen wie Google und das über eine eigene Domain steuern. Oder gleich über ein CDN. Dazu aber später mal mehr.

ga.js aktuell halten

Es gibt ja für jede Lösung ein Problem, so natürlich auch für mögliche Änderungen an ga.js, wenn man die Datei, um sie gzip-komprimiert auszuliefern, selber hosten will.

Ein bisschen Shell-Scripting sorgt dafür, dass die Datei von Google geladen und an die richtige Stelle kopiert wird:

#!/bin/sh
# TMP DIRECTORY
MYTMP=/tmp
# SAVE ga.js HERE
INSTALL_IN=/htdocs/domain.de/javascript/
# RESOURCE URL
GOOGLE_GA_URL=http://www.google-analytics.com/ga.js
# USER-AGENT
UA="Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3"
# CD TO TMP DIRECTORY
cd $MYTMP
# DOWNLOAD THE FILE
curl --header "Pragma:" -f -s -A "${UA}" -m 1800 --retry 15 --retry-delay 15 --max-redirs 8 -O $GOOGLE_GA_URL
# GIVE FILE CORRECT PERMISSIONS
chmod 644 $MYTMP/ga.js
# COPY FILE TO SITE DIRECTORY
cp -r $MYTMP/ga.js $INSTALL_IN
# RETURN TO OLDPWD
cd $OLDPWD
exit 0;

Als Cronjob ausgeführt wird damit ab sofort regelmäßig die aktuelle Version der ga.js von Google geholt.

Hält man sich darüber hinaus an die Empfehlung von Google und versieht seine statischen Dateien mit weit in der Zukunft liegenden Expire-Headern sollte man bei der Gelegenheit dann auch gleich sicherstellen, dass die Datei einen deutlich niedrigeren Expire-Header bekommt, sonst kann man sich die ganze Aktion auch gleich sparen:

<Files ga.js>
ExpiresByType application/javascript "access plus 1 week"
</Files>

Google vs. Google: ga.js gzip-komprimieren

Geschwindigkeit ist der neue heiße Scheiß. Google trommelt ganz vorne mit, klar, für die ist (Rechen-)zeit bares Geld. Das Firebug-Plugin Pagespeed gibt es schon länger, unter Let’s make the web faster hat der Suchmaschinenriese zahlreiche Informationen an zentraler Stelle gesammelt und seit kurzem hat auch eine Site Performance Auswertung Einzug in die Webmastertools gehalten.

Darin finden sich dann auch so interessante Sachen:
Google Site Performance bemängelt Google Analytics

Wirklich eine klasse Idee. Sollte Google vielleicht jemandem bei Google mal sagen.

Natürlich kann man die Datei auch selbst hosten.

Vorteile:

  • Man spart sich einen DNS-Lookup für www.google-analytics.com
  • Man kann die Datei komprimiert ausliefern
  • Eine Nichterreichbarkeit von www.google-analytics.com blockiert nicht den Ladevorgang

Auf der anderen Seite steht dem natürlich entgegen:

  • Der User hat, aufgrund der hohen Verbreitung von Google Analytics, die Datei möglicherweise schon im Cache
  • Ändert Google etwas an ga.js liefert man nach wie vor eine veraltete Datei aus.

Am Ende muss also jeder selbst entscheiden, ob sich für ihn das Einsparpotential durch die Komprimierung rechnet.