Frontend-Optimierung von Webanwendungen

Till Schulte-Coerne: Ich arbeite seit vier Jahren bei innoQ – ich hätte gedacht, das wär' dir bewusst. Ich mache relativ viel Webentwicklung und Webarchitektur.

Stefan Tilkov: Wir reden heute über Frontend-Optimierung, unser Kontext sind Webanwendungen. Wir reden davon, womit man sich beschäftigen kann, ganz unabhängig davon, in welcher Sprache so etwas realisiert ist. Wir haben zwar beide unsere Meinung dazu, was da gute Technologien wären, aber wir reden vor allem darüber, wie man den Frontend-Anteil einer Webanwendung optimieren kann und was man tun kann, um dafür zu sorgen, dass das gut ist, was immer auch “gut” bedeutet. Was bedeutet denn “gut” bei einer Webanwendung aus deiner Sicht?

Till Schulte-Coerne: Schnell natürlich!

Stefan Tilkov: Gibt’s auch noch andere Aspekte?

Till Schulte-Coerne: Andere Aspekte sind natürlich Dinge wie bedienbar, benutzbar, aber das was uns als Techies natürlich immer am meisten interessiert ist “schnell”, vielleicht zu Recht, vielleicht zu Unrecht … je nachdem, wie man das sieht.

Stefan Tilkov: Eine Sache, die man häufig wahrnimmt – das ist zumindest mein Empfinden – ist, das Leute sich wahnsinnig viele Gedanken darüber machen, wie sie ihre Datenbankzugriffe optimieren, wie sie besonders toll mit irgendwelchen Strategien ihr Backend optimieren, im Frontend eher weniger. Siehst du das auch so?

Till Schulte-Coerne: Das ist natürlich dem geschuldet, dass das, wo auf die Datenbank zugegriffen wird, also diese initiale Request/Response, wo irgend eine HTML-Seite zusammengekleistert wird, normalerweise das ist, womit wir uns so im alltäglichen Leben beschäftigen. Das ist aber meistens nicht das, was der Benutzer als sozusagen laderelevant ansieht. Oder nicht das Einzige. Für den Benutzer ist eine Seite natürlich erst dann fertig geladen, wenn sie aufhört zu flackern, wenn alle Bilder da sind, wenn alle Javascripts geladen und ausgeführt, fertig ausgeführt sind, wenn sozusagen die Seite zum Stillstand gekommen ist und keine blauen Bälkchen mehr irgendo herumflackern und noch Aktivität anzeigen. Und wenn man sich das halt so in üblichen Tools anschaut, z.B. Firebug für Firefox, oder im Webkit gibt’s auch Möglichkeiten dafür, im Internet Explorer vermutlich auch, weiß ich jetzt nicht, dann sieht man relativ gut meistens dass der Anteil, den dieses initiale Laden der Webseite ausmacht an diesem Gesamtladen im Endeffekt relativ wenig ist, viel weniger, als uns normalerweise bewusst ist, wenn man sich überlegt, wie viel Zeit wir in die Optimierung dieses einen Request/Response-Zyklus reinbuttern im Vergleich zum gesamten Aufkommen. Also üblicherweise, wenn man sich das anschaut, hab ich so eine subjektive Meinung, ist das beim initialen, ersten Besuchen einer Seite vielleicht noch mal 2/3 die da noch einmal oben draufkommen. 2/3 von diesem ersten Laden, wenn nicht sogar noch einmal genau so viel, manchmal dauert’s sogar noch mal doppelt so lange hinterher wie das Laden der HTML-Datei dauerte … das muss man sich einfach selber anschauen und man muss es auch selbst als Problem, das man auch beantworten muss, ansehen und natürlich auch lösen.

Stefan Tilkov: Im Prinzip kann man auch sagen, dass das was der Browser da eigentlich macht sind Client/Server, Distributed Communication Requests – da ist ein Programm, das spricht über das Netz mit einem anderen Programm. Normalerweise würde ich mir als Architekt wahnsinnig viele Gedanken darum machen, die Anzahl meiner Requests da gut zu gestalten, die richtige Granularität und so was alles da zu haben. Aber gerade scheint’s vielen Leuten furchtbar egal zu sein.

Till Schulte-Coerne: Sieht so aus. Die Dateien, die da meistens über die Leitung fliegen, sind dann natürlich auch meistens statisch, und damit scheint das irgendwie den Zuständigkeitsbereich von Software-Entwicklern zu verlassen. So sieht es halt aus. Aber effektiv müsste man sich auf jeden Fall Gedanken darum machen, jederzeit. Und vielleicht passiert das ja nach dieser Episode.

Stefan Tilkov: Dann erzähl doch mal, was man tun kann, also was wären Dinge, die man als Webentwickler tun kann, um die Frontend-Performance zu optimieren.

Till Schulte-Coerne: Also ein ganz entscheidender Punkt ist - und der rettet wahrscheinlich auch die meisten - dass man das, was einem der Browser bietet, nämlich das Caching, zunächst mal ausnutzt. D.h. die erste Seite, der erste Seitenbesuch wird üblicherweise relativ langsam vonstatten gehen, und danach fühlt’s sich dann schon etwas besser an, weil der Browser und sozusagen davor schützt, den ganzen Unsinn, den wir ihm aufgetragen haben, sich angeblich von Backend zu holen, sich dann tatsächlich zu holen. Das bedingt aber natürlich, dass ich ihn dazu überhaupt in die Lage versetze. Wenn ich nicht mal dem Browser-Cache die Chance gebe, mich zu retten, dann ist meine Seite wirklich lahm. Andere Dinge, die wichtig sind, sind das man häufig sieht, dass wen man eine HTML-Datei lädt, man eben daraus resultierend, zum Beispiel über Stylesheets, die wiederum Bilder repräsentieren, teilweise auch ganz kleine Schnipsel durch eine HTML-Seite eine Lade-Kaskade von, keine Ahnung, an die Hunderte von Requests gegen statische Schnipselchen, Bilder, CSS und JavaScript-Dateien anstößt. Und deswegen ist es natürlich unglaublich wichtig, dass man die Anzahl der Requests, die man indirekt anstößt, reduziert. Und das man sich dessen natürlich zunächst bewusst wird. Das muss man natürlich ein bisschen einschränken, denn das könnte irgendwann nicht mehr wichtig sein. Der Grund dafür, dass es wichtig ist, liegt darin begründet, dass aktuelle Browser zumindest solange man HTTP spricht, die Anzahl der parallelen HTTP-Verbindungen zum selben Server meistens auf ungefähr 6 beschränkt - früher waren’s mal 2, heute sind’s 6 parallele Verbindungen. Das heißt wenn ich 600 parallele Dateien irgendwo herunterlade, dann kann ich eben immer nur 6 parallel, gleichzeitig laufen lassen und habe 100 seriell hintereinander gefügte Downloadvorgänge wenn man so will, im Schnitt, was sicherlich nicht optimal ist.

Stefan Tilkov: Worauf du gerade angespielt hast war SPDY?

Till Schulte-Coerne: Richtig. SPDY - ich weiß jetzt gar nicht so richtig, da bist du ja eher der Experte, wie das mit HTTP 2.0 aussieht, ob das jetzt gleich SPDY ist oder nicht, aber diese Initiative von Google, das Web schneller zu machen, auf Protokollebene, auf HTTP-Ebene, ist eben SPDY, und SPDY erlaubt Multiplexing von von beliebig vielen Request/Response-Vorgängen durch ein und dieselbe TCP-Verbindung zur gleichen Zeit.

Stefan Tilkov: Also SPDY – nicht dass ich jetzt wahnsinnig viel mehr wüsste als du – wird wohl tatsächlich die Basis von HTTP 2.0 sein und bestimmt einiges davon adressieren, aber es dauert bestimmt noch ein Weilchen, bis das so weit verbreitet ist, dass man sich darauf verlassen kann.

Till Schulte-Coerne: Ja. Im Chrome kann man’s natürlich heute schon benutzen, aber der Aufwand, den man da mehr treiben muss, ist wahrscheinlich nicht ganz zu vernachlässigen für die meisten unserer Hörer, aber es ist vielleicht eine Option wenn man sich nicht grundsätzlich dieser Thematik stellen kann.

Stefan Tilkov: Also wir beschränken uns jetzt mal auf rein HTTP. Du hast das gerade gesagt, es gibt einen Mechanismus, da zu serialisieren, es gibt einen Mechanismus HTTP Pipelining, den man verwenden kann, mit dem man das zumindest theoretisch ein bisschen verbessern könnte, also ich kann viele Request abschicken, vorausgesetzt die machen nichts kaputt, kann ich die nacheinander abschicken ohne auf die Antwort zu warten. In der Praxis ist es so, dass HTTP Pipelining kaputt ist und deswegen nicht benutzt wird.

Till Schulte-Coerne: Genau, keiner macht das. Effektiv bedeutet das, dass man die Anfragen, die hintenraus folgen, mehr oder weniger serialisiert abfeuert, und nicht parallelisiert, wie es sich die meisten Leute vielleicht vorstellen oder manche Leute vielleicht vorstellen. Daraus ergeben sich dann natürlich schon ziemliche Probleme, was natürlich offensichtlich sein sollte.

Stefan Tilkov: Also lass uns noch einmal einen Schritt zurück gehen. Im Prinzip hast du gesagt das Wichtigste wäre, die Anzahl der Requests zu minimieren, also am besten auf 0, also zumindest nach dem initialen, denn wenn ich das einmal im Browsercache habe dann hole ich’s aus dem Cache und ich muss nicht mehr zum Server gehen.

Till Schulte-Coerne: Das ist etwas was zum Beispiel Google auf seiner Landing Page nicht ganz konsequent macht, aber die betten viel von dem Javascript einfach ein und betten auch CSS ein, um eben absolut Requests zu vermeiden, sodass wenn die HTML-Seite einmal da ist fast gar nichts mehr passieren muss. Das ist natürlich aus Sicht der Frontend-Optimierung ein Optimum, das ist aber wahrscheinlich aus Sicht eines Software-Architekten und auch aus meiner Sicht sicherlich eher ein Graus.

Stefan Tilkov: Das ist aber ein interessanter Punkt: Aus Architektursicht hätten wir das Ganze gerne schön modularisiert und wollen die Sachen nicht zusammenmatschen, aus Peformancesicht tun wir uns einen Gefallen, wenn wir nur einen Request machen und dann möglichst in einem Rutsch das übertragen.

Till Schulte-Coerne: Deswegen könnte es eine Option sein, dass man eben sagt man verlagert solche Aufgaben aufs Framework, sodass wir schön modularisiert programmieren können und das Framework dann im Prinzip dafür sorgt dass die Sachen nachher konkateniert und, was weiß ich werden sodass die Entwicklung unseren Idealen entspricht aber nach außen hin der Schmutz kommuniziert wird, den wir aus Performancesicht haben wollen. Da gibt es auch Frameworks, die das mehr oder weniger unterstützen, “Asset Pipelining” ist da so ein Begriff, das ist z.B. in Rails drin,mit dem man eben ein sehr modulares CSS- und JavaScript- Konzept haben kann und dann in der Lage ist, das auch effektiv alles zusammen zu packen, alles hochgradig auf CAching zu optimieren, aber trotzdem noch in der Lage ist, eine saubere Entwicklung zu haben.

Stefan Tilkov: OK, also wir haben die Anzahl der Requests minimiert, indem wir versuchen, Dinge zu kombinieren, sie also nicht künstlich auseinander zu reißen, sondern zusammen zu packen. Was wäre das nächste, wenn wir die Anzahl der Requests minimiert haben?

Till Schulte-Coerne: Ja das man dann natürlich wenn man Dinge überträgt, möglichst wenig überträgt. Das ist natürlich auch wieder relativ offensichtlich, würde ich schon fast sagen – dass man dann, wenn es möglich ist, wenig Dinge zu übertragen, das dann auch tut. Also Dinge z.B. zippt bzw. gezippt überträgt, was HTTP schon auf Protokollebene unterstützt und diese Sachen dann auch entsprechend einsetzt. Aber das ist natürlich von dem, wo unsere Softwarearchitektur noch Einfluss drauf haben kann, noch am geringsten relevant. Was wir eben direkt meistens beeinflussen können mit Software ist eben das Thema Anzahl der Requests, also Dinge zusammen packen und eben vor allem auch das Caching.

Stefan Tilkov: Was hältst du vom Minifizieren von CSS und JavaScript und ähnlichen Dingen?

Till Schulte-Coerne: Es gibt eben die Möglichkeit, dass man CSS und JavaScript minifiziert, also wenn man’s ganz naiv betrachtet könnte das z.B. bei JavaScript bedeuten, dass man als Entwickler weil der Code wartbar sein soll Dinge verwendet wie z.B. Leerzeichen oder lange Variablenbezeichner die über einen Buchstaben hinaus gehen – ich weiß auch nicht, wie man auf solche Ideen kommen kann, aber ich hab' gehört, dass das gutes Vorgehen ist – und es dann aber für das Funktionieren des Scriptes selber irrelevant ist, wie die Variable heißt oder nicht heißt. Deswegen kann man einfach hingehen und automatisiert z.B. Bezeichner einfach zusammendampfen, auf einen Buchstaben oder auf zwei Buchstaben, je nachdem, wie viele Bezeichner man hat. Und wenn man das automatisiert tut und das auch verlustfrei ist, dann ist das sehr sicher auch eine relativ gute Idee. Das Problem bei dieser Minifizierung im Allgemeinen ist dass sie nicht immer verlustfrei ist, sondern dass dadurch manchmal auch die Gesamtfunktionalität kaputt geht, weil der Minifizierer fehlerhaft arbeitet. Mir ist das z.B. vorgekommen bei Mobilfunkzugang auf Webseiten. Dort optimieren viele Mobilfunkprovider die Übertragung des JavaScript und CSS und das hat teilweise dazu geführt, dass das JavaScript bei mir nicht mehr ausführbar war. Welcher Fehler das ist, kann man natürlich nicht mehr sehen, weil JavaScript nur noch ein Klumpatsch von Buchstaben ist. Das Einzige was ich sehen konnte war, dass mein Browser einen Fehler geworfen hat, und das ist natürlich sehr unerfreulich. Deswegen: Wenn man das macht, dann muss man schon sehr genau wissen, was man da tut, bzw. besser noch, man muss testen, was das Ergebnis ist, weil man sich sehr bewusst sein muss, dass das doch fundamentale Eingriffe in den Code sind. Aber generell ist das sicher eine gute Idee.

Stefan Tilkov: Eine Variante ist sicher, die minifizierten Versionen von Bibliotheken zu benutzen. So etwas wie jQuery – die ganzen Dinge haben so etwas natürlich schon vorgefertigt.

Till Schulte-Coerne: Klar.

Stefan Tilkov: Was ich mich immer schon gefragt habe: Wenn man ohnehin zippt, ist es irgendwie total egal, ob ich da jetzt die Variable zusammenpacke, die “a” heißt oder “GreatBigVariableWithFancyName” – es kommt irgendwie das Gleiche dabei heraus, wenn ich die nachher zippe.

Till Schulte-Coerne: Aber im Prinzip wird’s immer noch einen Unterschied machen. Wir gehen deswegen typischerweise auch so vor, da wir viele Bibliotheken verwenden. Auch im JavaScript-Bereich versuche ich mich darauf zu verlassen, dass die die Bibliotheken Bereit stellenden auch die gezippten, nein gepackten Versionen getestet haben oder andere Leute, die diese Versionen verwenden, und meinen eigenen JavaScript-Code liefe ich auch häufig einfach so aus, damit man z.B. wenn irgendwelche Fehler auftauchen in der Lage sein kann, nachzufragen “Was ist denn genau kaputt”. Und dann kann man auch wirklich sehen: An der Stelle in der und der Datei ist das und das passiert. Und dadurch finde ich Fehler auch besser.

Stefan Tilkov: Du würdest also sagen: Man überträgt lieber die JavaScript-Datei in einer ordentlich lesbaren Form, dafür aber mit einem Caching-Header und separat, dann wird sie vom Browser gecacht, und wenn ich sie referenziere, dann ist es egal, ob sie einmal ein paar Byte mehr gehabt hat.

Till Schulte-Coerne: Genau. Ich würde an solchen Stellen sagen, dass ich dann vielleicht zusehen sollte, dass ich nicht viele JavaScript-Dateien einzeln übertrage, sondern stattdessen die Dateien effektiv untereinandere kopiere. Das kann man automatisiert machen und damit so, dass es nur ein Request ist, und wenn man das dann auch noch zippt, dann ist der Vorteil, den man dadurch bekommt, dass man das noch einmal auf inhaltlicher Ebene komprimiert, nicht mehr so groß. Aber für jemanden der eine Seite betreibt, wo unglaublich viele Leute initial drauf gehen, also keine interne Anwendung, wo immer dieselben fünf Leute drauf sind, als ein Beispiel, da spielt das sicherlich nicht so die Rolle, sondern eher eine Anwendung, die öffentlich irgendwo läuft, wo man ständig wechselndes Publikum drauf hat, da ist es sicherlich ein Argument und ist es hoffentlich auch drin das auch in der gepackten Version zu testen.

Stefan Tilkov: Die eine Variante, Dinge zusammenzubringen ist das, was du gerade gesagt hast, also Dinge untereinander zu kopieren. Zum Thema Einbetten fallen mir noch data:-URIs ein?

Till Schulte-Coerne: Ich habe jetzt eben viel über JavaScript geredet. Da gibt es keine so einfache oder direkte Möglichkeit, Dinge nachzuladen, deswegen ist JavaScript ein Thema, das sich relativ schnell erschöpft. Bei CSS ist das anders, denn CSS kann auch selber wieder Dateien referenzieren, insbesondere Bilder, nicht unbedingt CSS-Dateien – geht zwar auch, aber effektiv referenziert man häufig aus CSS Bilddateien. Und ein Vorgehen ist zu versuchen, dass man nicht zu viele Bilddateien aus CSS heraus referenziert. Wenn ich eh eine statische CSS-Datei habe, an der ich nichts ändere, weil sie hoffentlich nicht dynamisch pro User generiert wird, sondern irgendwo auf meinem Server liegt, kann ich auch ein bisschen Arbeit investieren und eine Datei erstellen, die bezüglich der Zugriffe, die daraus resultieren, optimiert ist. Da gibt es verschiedene Techniken. Eine der älteren, klassischen Möglichkeiten ist, dass man Bilder zusammenfasst, Spriting nennt sich das. Also wenn man eine Seite hat, die sich sehr vieler Icons bedient – der klassische Stift fürs Editieren und das X fürs Löschen – dann ist es meistens eine gute Idee, wenn man diese ganzen Bilder auf ein Bild, also in einen Request vereint und dann mit der Technik, dass man Hintergrundbilder in Buttons oder in div-Bereichen verschieben kann, den relevanten Ausschnitt aus dieser “Tapete” von Bildern extrahiert. Das sieht man relativ gut, wenn man sich jQuery UI anschaut, die mit einer reichhaltigen Button- oder Icon-Bibliothek daherkommen: Da wird jQuery UI mit so einer riesigen Tapete von Icons ausgeliefert, und das CSS, das mitgeliefert wird, kümmert sich darum, dann entsprechend von Klassen, die man relativ leicht setzen kann, den entsprechenden Ausschnitt aus dieser Tapete zu extrahieren oder einzustellen. Das ist eine relativ aufwändige Methode, natürlich, weil mein CSS dadurch, wie dieses Bild aussieht, beeinflusst wird, weil ich natürlich entsprechend andere Ausschnitte auswählen muss. Also wenn sich dieses Bild ändert, muss ich üblicherweise mein CSS anfassen und kann das schlecht automatisieren.

Stefan Tilkov: Was du gerade geschildert hast, ist eine der typischen Sachen, wegen der Leute das Web nicht leiden können. Ätzend!

Till Schulte-Coerne: Furchtbar. Fieselei ohne Ende, das ist einfach ein Hack. Aber es gibt mittlerweile zum Glück ein bisschen schönere Lösungen. Wir benutzen relativ häufig data:-URIs. Das ist die Möglichkeite, in eine URI ganze Responses sozusagen einzukodieren. Beginnt mit “data:”, dann spezifiziert man einen MIME-Type der folgenden Daten, und dann kommtn Base64-enkodiert in der selben URI der Inhalt. Und es ist relativ offensichtlich, dass es eine absolut bescheuerte Idee ist, wenn die Datei größer ist, das zu tun, aber wenn man wirklich nur von so ganz kleinen Bildchen redet, dann ist das eine gute Möglichkeit um so ein kleines 8x8- oder 16x16-, heute ist es vielleicht eher 64x64-Pixel-Bildchen, oder noch viel mehr mit hochauflösenden Displays

• aber trotzdem ist es immer noch möglich so ein Bild einfach da einzubetten. Dadurch ist man in der Lage, sämtliche Bildinhalte, die zumindest klein genug sind, in seiner einen CSS-Datei mit auszuliefern, und das kann ich dann natürlich auch wieder Framework-unterstützt machen. Da muss ich dann eben dafür sorgen, vielleicht auch gar nicht Framework-unterstützt, aber ich muss dann diese CSS-Datei parsen und kann dann hingehen und statische, klassische URL-Referenzen so wie man sie eigentlich macht einfach automatisch durch den entsprechenden Dateiinhalt ersetzen. Und das ist dann aus meiner Sicht auch gut automatisiert machbar, was eben das Schöne an dieser Lösung ist. Der Nachteil ist Internet Explorer-Kompatibilität: Ich weiß nicht ganz genau die Nummer, aber ältere IE-Versionen unterstützen die data:-URIs nicht und damit habe ich dann natürlich Probleme.

Stefan Tilkov: Was haben wir noch? Fonts gibt’s noch, oder?

Till Schulte-Coerne: Und dann haben wir noch … genau, Fonts. Das ist jetzt gerade, – oder ich weiß nicht, eigentlich ist es schon nicht mehr hip, denn es ist mindestens schon ein halbes Jahr alt, also braucht man schon fast gar nicht mehr davon zu reden – man hat das irgendwann mal gesehen, wenn Leute häufiger mal auf GitHub aktiv waren. Ich bin irgendwann einmal auf GitHub gekommen und habe mich gewundert, warum sind die Seite auf einmal so bescheuert aus –

Stefan Tilkov: So monochrom?

Till Schulte-Coerne: Genau, die sah monochrom aus, und der Grund dafür war, dass sie ihre Icon-Bibliothek umgestellt haben, nämlich von Bildern, wie auch immer sie die gemacht haben, das habe ich mir nicht so genau angeguckt, wahrscheinlich waren’s Sprites, auf Fonts. Also die haben einen eigenen Font, einen Webfont erstellt, der ihre eigene Icon-Bibliothek abbildet, und haben dann im Prinzip dafür gesorgt, dass an den entsprechenden Stellen die richtigen Buchstaben stehen. Das macht man dann klassischerweise auch mit CSS. Also irgendein kryptischer Buchstabe, der dann dafür sorgt, dass an dieser Stelle das richtige Icon steht. Da gibt es auch Fontbibliotheken, Font Awesome zum Beispiel –

Stefan Tilkov: Helveticons heißen die, die wir benutzen, auf unserer Website –

Till Schulte-Coerne: Genau. Nein, ich meine unserer Seite wäre kein Webfont

Stefan Tilkov: Das schauen wir noch mal nach …

Till Schulte-Coerne: Der Kollege hat sich immer sehr darüber aufgeregt. Diese Fontbibliotheken kommen dann üblicherweise mit dem Fontsatz und einer ganzen Menge von CSS-Regeln, die dafür sorgen, dass ich nicht das UTF-Zeichen 07-Irgendwas an die Stelle xy einfügen muss, wo ich eben dieses Icon haben will, sondern ich kann diese Stelle über einen Klassenselektor entsprechend stylen, und das CSS kümmert sich darum, dass an dieser Stelle das richtige Symbol erscheint, oder der richtige Buchstabe.

Stefan Tilkov: Ein Riesenvorteil ist natürlich, dass das Vektoren sind.

Till Schulte-Coerne: Das ist aber auch wieder der Nachteil.

Stefan Tilkov: Warum ist das ein Nachteil?

Till Schulte-Coerne: Das war der Ausgangspunkt, warum GitHub für meine Augen so trist aussah. Ich hab gedacht, was ist denn da passiert – der Grund ist, dass das nur noch zwei Farben sind.

Stefan Tilkov: Das hat mit den Vektoren ja nichts zu tun. Der Vorteil ist Vektor, der Nachteil ist Monochrom.

Till Schulte-Coerne: Genau. Es gibt keine Grauwerte mehr, es gibt nur noch schwarz/weiß, wobei uns als Informatikern sollten Nullen und Einsen natürlich am Herzen liegen.

Stefan Tilkov: Und sowieso ist es in Zeiten des Minimalismus – da passt das ohnehin viel besser.

Till Schulte-Coerne: Das mag sein, ja.

Stefan Tilkov: Und da rollen sich uns nicht ganz so die Zehennägel hoch. Man könnte sagen ein Font dazu zu benutzen, naja, OK, aber man kann ja sagen, es ist eine effiziente Variante, Vektorgraphiken zu übertragen. Reden wir uns das schön, dann klappt das schon.

Till Schulte-Coerne: Es gibt Fontbibliotheken, die man verwenden kann, um Graphen zu zeichnen. Da schreibt man entsprechende Zeichenketten in seinen Code hinein und die Fontbibliothek sorgt dann dafür, dass das im Prinzip als Balkendiagramm z.B. dargestellt wird. Das geht dann noch mal deutlich weiter. Insofern ist das vielleicht noch vertretbar.

Stefan Tilkov: OK. Wir haben jetzt ein paar Tricks diskutiert. Wir wollen das Caching nutzen um die Anzahl der Requests zu minimieren. Wir wollen das Datenvolumen minimieren, Dinge einbetten, kombinieren, das waren so die Sachen, glaube ich. Wie bekomme ich denn heraus, ob ich überhaupt ein Problem habe? Ist meine Seite schnell genug, hab ich schon alles getan? Was hast Du an Tipps?

Till Schulte-Coerne: Wenn ich eine ganz tolle Seite habe, die super ist von Funktionalität und Layout, und keiner benutzt sie, könnte das ein Hinweis sein, aber das wäre sicher nicht der Hinweis, den man sich erhoffen würde. Sondern natürlich wollen wir das auch selber überprüfen können, würde ich mal behaupten, und die gute Antwort in diesem ganzen Frontend-Optimierungsbereich, zumindest dem Web-Frontend-Optimierungsbereich ist dass man da relativ weit mit Tools kommt. Ich bin eigentlich jemand, der nicht so sehr an Tools glaubt, aber im Umfeld von Webfrontends würde ich da absolut keine Alternative zu sehen. Es gibt zwei Dinge, die relativ auf der Hand liegen, die man da verwenden kann. Das eine ist YSlow, von Yahoo, das ist ein Plugin in den Firebug von Firefox. Ich hab’s neulich mal ausprobiert: Man kann YSlow installieren, ohne Firebug installiert zu haben, ohne auch eine Fehlermeldung zu kriegen. Das führt dann aber zu nichts. Man muss zuerst den Firebug installieren, auch wenn Firefox im Kern schon die Inspektorfunktionalität, die der Firebug eigentlich mitbringt, schon im Kern selber mitliefert. Man hat das dann halt leider doppelt im Firefox. YSlow, und das Andere ist Pagespeed, von Google, basieren darauf, d.h. erst den Firebug herunterladen. Mit diesen Tools kann man die Seite, die man aktuell im Browser sieht, überprüfen lassen. Dann geht kurz ein kleiner Ladebalken an, und danach bekomme ich in beiden Fällen Scores angezeigt, also Management-verwertbar sozusagen präsentiert, wie schnell und gut meine Webseite ist. Was daran toll ist, ist eigentlich weniger dieser Score, sondern vielmehr die Reichhaltigkeit der Informationen, die dann kommt. Also man kann sich auch bei Sachen, die man gut macht, aber auch bei Sachen, die optimierungswürdig sind, sehr detailliert durchlesen, was da genau das Problem ist und dann entsprechend reagieren. YSlow referenziert sehr häufig Dokumentation bei Yahoo, während Pagespeed sogar so weit geht, dass es für viele Dinge sogar schon direkte Alternativen bereitsstellt. Bei Pagespeed könnte man z.B. wenn man Bilder in einer zu hohen Qualität bereitstellt, schlägt Google, die hinter Pagespeed stehen, üblicherweise vor, diese Bilder in etwas schlechterer Qualität vorzuhalten.

Stefan Tilkov: Und gibt einem dann gleich einen Link, auf den man klicken kann.

Till Schulte-Coerne: Genau, man kann direkt das Bild herunterladen, man kann direkt sehen, die Unterschiede sind so und so groß, man kann sich beide Bilder anschauen und dann selber für sich entscheiden, ob das akzeptabel ist, und meistens haben die dann doch recht, wenn die das vorschlagen. Also das heißt, um Tools ist in dem Bereich einfach kein Herumkommen, weil die Tools einfach sehr gut sind. Witzig ist auch, dass sie immer unterschiedliche Dinge anmarkern. Wenn man nicht ganz offensichtliche Fehler macht, dann kann man auch durchaus beide mal laufen lassen, und die werden dann auch häufig beide ihren Mehrwert noch liefern.

Stefan Tilkov: CDNs haben wir übrigens vergessen. Die tauchen auch immer noch auf, als Empfehlung. Kannst Du kurz erklären, was sich dahinter verbirgt?

Till Schulte-Coerne: YSlow markert das bei uns immer an, als Hauptpunkt auf unseren Webseiten, weil wir häufig diese Tools verwenden. Also wir müssen jetzt, bevor wir diesen Podcast ausstrahlen, vielleicht noch einmal schauen …

Stefan Tilkov: Unbedingt!

Till Schulte-Coerne: Wenn wir diese Tools verwendet haben, dann bleibt immer ein Punkt bei uns, und der heißt “Use CDNs”, Content Delivery Networks. Und CDNs sind Einrichtungen, die alles darauf optimieren, diese statischen Assets, die normalerweise mit Webseiten so einher gehen, ganz furchtbar schnell und sogar geo-lokal nah an die Leute, also an den Endbenutzer auszuliefern. Das ist eben ein Punkt – das muss man akzeptieren. Wenn man eine sehr große Website hat, mit vielen Assets wie z.B. Videos usw. und man eine große Anzahl von Leuten erreichen und auch begeistern will, davon, dass das Video auch wirklich schön anzusehen ist, dann gibt es sicherlich überhaupt kein Darumherumkommen um so ein Content Delivery Network, während das in einer internen Anwendung natürlich diskutabel ist. Einen Kernpunkt, ich hab’s kurz gesagt, muss man vielleicht noch einmal unterstreichen, von CDNs ist eben diese Nähe, die Nähe zum Endkonsumenten. Wenn ich in Deutschland bin, und meine meisten Kunden sind in Deutschland, und ich relativ viel Geld dafür bezahle, eine dicke Anbindung von meinen eigenen Servern ins Internet zu haben, dann ist der Vorteil wahrscheinlich nicht so groß wie wenn ich ein globaler Player bin, aber trotzdem mein Rechenzentrum nur in Deutschland betreiben will, wobei die Frage ist, ob das funktioniert. Aber mal angenommen, das würde funktionieren, dann habe ich relativ viel davon, wenn sich mein Content Delivery Networkbetreiber darum kümmert, dass dan meine Filme wenigstens nicht jedesmal von Brunsbüttel nach Shanghai über die Leitung gehen müssen, sondern vielleicht schon mal in Shanghai vorliegen. Diese CDNs gehen, je nachdem, welchen man wählt, sehr nah an die Endkunden dran und betreiben sogar innerhalb von Unterverteilern von Netzzugangsprovidern häufig schon eigene Server, sodass man quasi schon Stadt- lokal ist. Ich muss jetzt glaube ich auch den Namen nennen. In dem Fall ist das eigentlich nur Akamai, die das in der Nähe bieten, zumindest so weit ich weiß. Es gibt ganz viele Alternativen, z.B. von Amazon, Cloudfront, kann ich verwenden, um Daten, die bei S3 liegen, weltweit zu verteilen. Google hat sicherlich auch Lösungen, die so etwas machen. Google wird sicherlich auch Verträge haben mit irgendwelchen Telekommunikationsanbietern, aber Akamai ist da eben sehr stark spezialisiert und kümmert sich auch um Dinge wie z.B. die Auslieferung von Video-Previews von irgendwelchen Kinofilmen oder Auto- Imagevideos und ähnliche Dinge, weil z.B. ein Autolieferant oder ein Autohersteller niemals bereit wäre, zu akzeptieren, dass das Video seines neuen Modells auf der Webseite ruckelt oder Ladeverzögerungen hat, und sei es auch noch so kurz. Da gibt es unglaublich viel Optimierungspotenzial nach oben, je nachdem, wie viel Geld man hat oder bereit ist zu investieren.

Stefan Tilkov: OK. Lass uns vielleicht langsam zum Abschluss kommen. Was wären ein paar konkrete Handlungsempfehlungen, die man Hörern mitgeben kann. Sollte man sich darum überhaupt kümmern, und wenn ja, was tut man jetzt als nächstes. Was mache ich, wenn das interessant klingt, aber ich jetzt wissen will, wie ich weitermache?

Till Schulte-Coerne: Ich denke natürlich, dass man sich darum kümmern sollte, weil ich fest davon überzeugt bin – das mag einem Softwareentwickler vielleicht nicht so gefallen, aber was halt unglaublich wichtig für die Akzeptanz bei Normalsterblichen ist, und sei es auch noch so ein kleiner Kreis, ist eben einerseits, dass das UI gut aussieht, dazu haben wir jetzt wenig gesagt, aber auch vor allem, dass das UI sich gut anfühlt, dass es schnell ist, dass ich nicht Ewigkeiten warten muss. Und wenn ich die Akzeptanz meiner Software verbessern will, dann muss ich dafür sorgen, dass solche Dinge wie die Geschwindigkeit des Seitenaufbaus optimal oder gut sind. Und wenn ich irgendwann eingesehen habe, dass das eine gute Sache ist, und vielleicht auch dann, wenn ich eingesehen habe, dass das auch überhaupt nichts Schwieriges ist, dann kann ich hingehen und kann mir YSlow oder Google Pagespeed herunterladen, einfach installieren, das geht alles sehr einfach, mir die Seite öffnen, die ich mal analysieren will, also klassischerweise vielleicht die Landing Page, und das einfach mal analysieren lassen und schauen, was dabei herumkommt. Meistens sind da, immer wenn wir das bei unseren Kunden mal gemacht haben, sind da so ein paar Sachen dabei, die innerhalb von zwei Sekunden konfiguriert sind – na ja, sagen wir mal zwei Stunden vielleicht konfiguriert sind, je nachdem wie kompliziert der Umgang mit dem Betrieb das ist, aber im Prinzip absolut problemlos umzusetzen sind. Das ist schon eine tolle Sache eigentlich.

Stefan Tilkov: Gut, Till – vielen Dank und bis zum nächsten Mal und danke fürs Zuhören!