Warum eine Pagespeed-Optimierung auch in Zeiten von VDSL und LTE noch sinnvoll ist

In Gesprächen mit Website-Betreibern hört man häufig die Aussage, man müsse die eigene Ladezeit optimieren, da dies seit einigen Jahren ein Google-Rankingfaktor sei. Obwohl diese Aussage faktisch nicht komplett falsch ist, wird an dieser Stelle häufig zu einfach gedacht.

Ein anderes Bild ergibt sich, wenn man die Ladegeschwindigkeit unter Gesichtspunkten der User Experience (UX) betrachtet. Diese ergibt sich aus diversen Webseite-Bausteinen wie Design, Nutzerführung, Zugänglichkeit, Interaktion oder Inhalt. Allerdings haben diese Punkte gemein, dass ihr Erfolg im Sinne einer positiven UX von der Erwartungkonformität des Besuchers abhängt.

Anders sieht es beim Thema Pagespeed aus. Niemand, unabhängig von Alter, Geschlecht oder Nationalität, wartet gerne. Durch eine Verbesserung der Ladezeit kann man sich also sicher sein, jedem Besucher der Webseite eine verbesserte Nutzererfahrung zu bieten. Umfangreiche Split-Tests oder Eyetracking-Studien, die bei anderen UX-Optimierungen notwendig wären, kann man sich sparen.

Pagespeed-Analyse und die Rolle von Google PageSpeed Insights

Häufig wird die von Googles PageSpeed Insights errechnete Punktzahl zwischen 1 und 100 gleichgesetzt mit dem Optimierunggrad einer Website. Natürlich gibt der vom Tool ausgespuckte Wert einen guten Überblick, sollte aber nie mehr als ein erster Indikator sein. Schließlich unterliegt die Punktzahl wie jeder andere maschinell errechnete Wert den Fesseln seines eigenen Algorithmus. Es kann sogar vorkommen, dass von PageSpeed Insights vorgeschlagene Empfehlungen im Kontext des gesamten Webprojekts betrachtet eher negative Auswirkungen hätten.

100 Punkte sehen zwar gut aus, sind aber nicht immer erstrebenswert!

Die Auswertung der vom Tool empfohlenen Maßnahmen kann dementsprechend nur ein Teil einer Pagespeed-Analyse darstellen. Mindestens genauso wichtig ist es, sich mit den Entwicklerwerkzeugen seines Browsers hinreichend vertraut zu machen. Hier ergeben sich nämlich bereits mit wenigen Klicks umfangreiche Möglichkeiten, sich einen detailierten Überblick des Optimierungsgrades einer Webseite zu verschaffen. Im Falle des Chrome-Browsers sollte man sich intensiv mit dem “Network”-Reiter beschäftigen. Wer später noch tiefer einsteigen möchte, findet unter dem Punkt “Timeline” weitere spannende Einblicke.

Mit den Chrome oder Firefox Developer Tools lässt sich eine Website vollständig auseinandernehmen – auch im Bezug auf den Pagespeed.

Dennoch soll die Rolle des PageSpeed Insights Tools an dieser Stelle natürlich nicht heruntergespielt werden, da es vielen Webworkern einen simplen Einstieg in das Thema bietet. Auch bei den Optimierungsmaßnahmen, die im weiteren Artikelverlauf vorgestellt werden, wird man ohne Probleme einen Bezug zum jeweiligen Tipp von Googles Tool herstellen können.

Die drei Säulen der Pagespeed-Optimierung

Fast sämtliche Maßnahmen der Pagespeed-Optimierung lassen sich in drei Kategorien einordnen:

Reduzierung von http-Requests

Das Reduzieren von http-Requests ist in der Regel die wichtigste Optimierungsmaßnahme und gleichzeitig ein Punkt, bei dem die meisten Webseiten noch großes Potential aufweisen. Unter einem http-Requests versteht man die Anfrage des Clients (Browser), sowie die entsprechende Antwort vom Server. Neben dem initialen HTML-Dokument werden bei jedem Seitenaufruf meist dutzende weitere Ressourcen vom Server angefordert, die jeweils einen eigenen Request erzeugen. Wir reden hier in der Regel von Bild-, CSS- und Javascript-Dateien, aber auch eingebettete Schriftarten oder AJAX-Aufrufe erzeugen natürlich einen http-Request.

Vor allem zwei Gegebenheiten sind dafür verantwortlich, dass jeder einzelne http-Requests die Ladezeit erhöht. Zum einen befolgen selbst moderne Browser noch die Regel, nicht zu viele Requests vom selben Server gleichzeitig zu laden. Die aktuellen Versionen von Google Chrome und Mozilla Firefox erlauben beispielsweise höchstens sechs parallele Verbindungen. Dieses Verhalten ist zum einen sinnvoll, da Server sonst, in etwa vergleichbar mit einer DDoS-Attacke, schnell in die Knie gehen könnten. Zum anderen bedeutet dies aber auch, dass Webseiten die mehr als beispielsweise sechs Ressourcen benötigen, die Dateien in mehreren Durchgängen herunterladen müssen.

Ein weiterer Nachteil des Hypertext Transfer Protocol (HTTP) in der Version 1.0 oder 1.1 ist, dass jeder http-Requests in der Regel Informationen übertragt, die an der jeweiligen Stelle gar nicht verwendet werden. Hier unterscheidet man zwischen des Request Headers (Anfrage vom Client an den Server) und Response Headers (Antwort des Servers). Vor allem bei ersteren werden häufig unnötige Daten übertragen. Ein schönes Beispiel sind statische Bild- oder CSS-Dateien, die in den Requests Headers sämtliche der Domain zugewiesenen Cookies erhalten, obwohl diese natürlich an keiner Stelle benötigt werden.

Auch wenn sich beide Punkte vielleicht trivial anhören, so sollte man die Reduzierung von http-Requests als Maßnahme der Pagespeed-Optimierung auf keinen Fall unterschätzen. Weit über 100 Requests bei einem einzelnen Seitenaufruf sind nämlich weniger die Ausnahme als viel mehr die Regel.

Verkleinerung der zu übertragenden Dateimenge

Natürlich lässt sich nicht jeder http-Request einfach streichen, schließlich müssen Inhalte und Funktionalitäten ja irgendwo her kommen. Jedoch gibt es einige Möglichkeiten, die Größe einer Datei zu reduzieren. Im weiteren Verlauf des Artikels werden hierzu entsprechende Maßnahmen vorgestellt. Besonders erstrebenswert sind natürlich Techniken, die eine automatische Reduktion erzielen, ohne das man selbst an der Datei herumschrauben muss.

Ressourcen in die richtige Reihenfolge bringen

Dieser Punkt macht in der Praxis meist den Unterschied zwischen schnellen und super schnellen Webseiten aus, birgt dafür aber auch die größte technische Komplexität. Grob gesagt geht es darum, die vom Server zu ladenden Ressourcen in die richtige Reihenfolge zu bringen, um dadurch wichtige Inhalte unmittelbar sichtbar zu machen. So entsteht der subjektive Eindruck einer wesentlich kürzeren Ladezeit. Allerdings sind dafür meist tiefgreifende Eingriffe in die Technik einer Webseite erforderlich, weshalb entsprechende Maßnahmen in diesem Artikel nur angerissen werden können.

Fallbeispiel #1: bild.de

Die ersten zwei Maßnahmen zur Optimierung der Ladegeschwindigkeit lassen sich gut am Beispiel der Website der auflagenstärksten deutschen Zeitung festmachen.

Statische Ressourcen reduzieren

Unter der Reduzierung von statischen Ressourcen versteht man beim Thema Pagespeed-Optimierung die Bereinigung unnötiger Zeichen in HTML-, CSS- und Javascript-Dateien, die für die korrekte Ausführung nicht notwendig sind. Dies können doppelte Leerzeichen, Zeilenumbrüche, Tabulatoren, aber auch umfangreiche Kommentare sein. Solange man seinen Code sauber formatiert, ist es dem Browser natürlich egal, ob Zeilen korrekt eingerückt oder Funktionen hinreichend kommentiert sind; er benötigt diese Informationen nicht.

Am Beispiel von bild.de ließen sich so immerhin gut 30 KB an zu übertragender Dateimenge einsparen. Heruntergebrochen auf die Dateien, welche nicht reduziert sind, ergäbe dies eine prozentuale Ersparnis von knapp 10 Prozent.

Weder schön noch lesbar, dafür aber schnell: Reduzierter Code

Die Reduzierung von statischen Ressourcen ist meistens schnell erledigt. So stehen diverse Online-Tools wie jscompress.com (Javascript), cssminifier.com (CSS) oder htmlcompressor.com (HTML) zur Verfügung. Für Webentwickler ist es hingegen erstrebenswert, einen Reduzierungs-Prozess direkt in die eigene Entwicklungsumgebung (IDE) zu integrieren. Dies funktioniert beispielsweise hervorragend mit Task Runnern wie Grunt oder gulp.js. So ist sichergestellt, dass man weiterhin über eine (hoffentlich) gut dokumentierte Entwicklungsversion einer Datei verfügt, auf dem Produktivsystem aber automatisch die reduzierte Variante landet.

Javascript- und CSS-Dateien kombinieren

Ging es beim vorherigen Punkt noch um die Reduzierung der Dateigröße, so möchten wir nun die Anzahl an http-Requests verringern. Dies lässt sich unter anderem erreichen, in dem man Javascript- und CSS-Dateien jeweils zusammenlegt. Gerade beim Einsatz von Content Management Systemen wie WordPress werden nicht selten mehr als ein Dutzend verschiedener CSS- und Javascript-Dateien geladen. Meist lässt sich dies nicht vermeiden, schließlich müssen die Plugin-Entwickler ihre Funktionalitäts- und Design-Anweisungen ja irgendwo mitgeben. Einen negativen Einfluss auf die Ladezeit hat es dennoch.

Gerade bei bild.de ist dieser Effekt enorm. So werden alleine über 70(!) einzelne Javascript- und immerhin zehn CSS-Dateien vom Server angefordert. Natürlich sind in diesem Fall sehr viele Script-Einbettungen den externen Werbe-Anbietern geschuldet. Im Zuge der Optimierungsmaßnahme “Reduzierung von http-Requests” bestünde aber an dieser Stelle noch riesiges Optimierungspotential.

bild.de lädt bei einem einzelnen Seitenaufruf über 70 Javascript-Dateien!

Vor allem das Kombinieren von CSS-Dateien ist meistens nicht sonderlich schwer. Hier ist lediglich zu beachten, dass die Inhalte der Dateien in der exakt selben Reihenfolge wie vorher eingefügt werden. Ansonsten könnten sich Selektoren irtürmlich gegenseitig überschreiben. Wer bereits mit SASS oder LESS arbeitet, hat dank @import an dieser Stelle sowieso kein Problem.

Schwieriger wird es häufig bei Javascript-Dateien, da diese untereinander Abhängigkeiten aufweisen können. Beispielsweise wird ein kritischer Fehler erzeugt, wenn ein Script die jQuery-Bibilothek benötigt, diese aber noch gar nicht zur Verfügung steht. Ähnlich wie bei den CSS-Dateien muss man also auch hier die korrekte Reihenfolge beachten sowie sicherstellen, dass der Javascript-Quellcode absolut korrekt formatiert wurde. Ein fehlendes Semikolon am Zeilenende kann hier bereits viel Ärger bedeuten.

Wie bereits beim letzten Punkt sollte der moderne Webentwickler auch die Aufgabe des Kombinierens direkt von seiner IDE via Task Runner erledigen lassen. Falls ein Deployment-Prozess existiert, könnte dieser Schritt aber auch hervorragend hier durchgeführt werden.

Fallbeispiel #2: zalando.de

Auch am Beispiel des großen deutschen Online-Shops zalando.de lassen sich drei Optimierungstechniken exemplarisch erklären.

Browser-Caching nutzen

Zumal man keine Single Landing Page betreibt, ist es die Regel, dass Besucher nicht nur ein, sondern hoffentlich möglichst viele Seiten aufrufen. Aber auch Stammbesucher könnten mehrmals wöchentlich die eigene Webseite besuchen. In beiden Fällen ist es sinnvoll, dem Browser mitzuteilen, wie lange er statische Ressourcen (CSS-, Javascript- oder Bild-Dateien) im eigenen Cache behalten darf. So müssen sie nicht bei jedem Seitenaufruf neu vom Server angefordert, sondern können direkt von der lokalen Festplatte des Nutzers geladen werden. Dadurch spart man gleich doppelt, denn man reduziert die zu übertragende Dateimenge und die Anzahl an http-Requests.

Im Falle von zalando.de wird selbst für sehr allgemeine, seitenübergreifende Elemente kein Ablaufdatum festgelegt. Dies betrifft beispielsweise statische Bilder wie das Logo, den eigenen Icon-Font aber auch die wichtigste CSS-Datei. So ist der Browser mit seiner Entscheidung auf sich allein gestellt und entscheidet sich im Zweifel dafür, bei jedem Seitenaufruf einer Unterseite sämtliche Ressourcen neu vom Server anzufordern.

Statische Ressourcen wie das Logo oder CSS-Dateien werden bei Zalando nicht gecached

Google PageSpeed Insights empfiehlt für statische Ressourcen mindestens eine Haltbarkeit von einer Woche. Man kann jedoch einen wesentlich höheren Zeitraum definieren. Wenn man auf Nummer sicher gehen will, dass Benutzer keine alten Dateien ausgespielt bekommen, ergänzt man den Dateinamen bei jedem Update um einen Zeitstempel (z.B. von “style-1-1-2015.css” auf “style-15-2-2015.css”).

Betreibt man einen Apache-Webserver lässt sich das Browser-Caching sehr einfach über die .htaccess-Datei definieren. Die Deklaration erfolgt dabei über den Mime Type.

Statische Ressourcen komprimieren

Unter der Komprimierung statischer Ressourcen versteht man die serverseitige Aktivierung einer Kompressionstechnik wie gzip oder deflate. Ähnlich wie man es von einem ZIP-Archiv kennt, werden Dateien dabei vom Server komprimiert und dann an den Client (Browser) geschickt. Dieser ist dafür zuständig, die Dateien vor der Verwendung wieder zu dekomprimieren. Die dadurch eingesparte Dateimenge ist vor allem bei Ressourcen mit häufig wiederkehrenden Textmustern wie CSS-Dateien enorm.

zalando.de liefert uns dafür ein schönes Beispiel. Zwar werden fast alle Dateien komprimiert ausgeliefert; die zwei, welche nicht komprimiert werden, zeigen jedoch eindrucksvoll, welches Potential diese Technik bietet. So kommt alleine eine Javascript-Datei auf eine Dateigröße von 58 KB. Komprimiert wäre sie hingegen nur gut 10 KB groß. Eine Einsparung von 48 KB oder 83 Prozent. Im Falle einer immer noch weit verbreiteten EDGE-Verbindung könnte nur durch die Komprimierung dieser Datei die Ladezeit um zwei bis drei Sekunden gesenkt werden.

Ähnlich wie beim letzten Punkt lässt sich auch hier eine Komprimierung über die .htaccess-Datei des Servers aktivieren.

Bereits komprimierte Dateien wie Bilder oder bestimmte Schriftformate sollten von der serverseitigen Komprimierung ausgeschlossen werden.

Fallbeispiel #3: bundestag.de

Auch die offizielle Webseite des deutschen Bundestages liefert uns zwei gute Fallbeispiele.

Antwortzeit des Servers reduzieren

Google PageSpeed Insights bemängelt im Falle von bundestag.de eine lange Antwortzeit des Servers. Diese Fehlermeldung wird ausgegeben, sobald der Server länger als 200 ms benötigt, das initiale HTML-Dokument zur Verfügung zu stellen. Bei bundestag.de sind es meist über 400 ms. Damit betrifft dieser Hinweis die Ausführungszeit der serverseitigen Scripte; also nicht HTML oder Javascript, sondern PHP, Java, Ruby on Rails oder natürlich auch sämtliche Datenbankabfragen.

Hier einen pauschalen Optimierungstipp zu geben, ist relativ schwierig. Schließlich ist zur Ermittlung von Flaschenhälsen eine genaue Code-Analyse notwendig. Bei komplexen Content Management Systemen oder Online-Shops sollte man aber auf jeden Fall – sofern noch nicht vorhanden – über eine serverseitige Caching-Lösung nachdenken. Diese schreibt im Idealfall die fertig generierten HTML-Dateien in regelmäßigen Zeitabständen auf die Festplatte des Servers. Ruft ein Besucher dann die Webseite auf, ist eine Aktivierung der serverseitigen Scripte gar nicht mehr notwendig; stattdessen wird einfach das Abbild aus dem Cache an den Browser geschickt. Durch Einsatz dieser Technik sollte es in der Regel kein Problem sein, unter die 200 ms zu kommen.

Große Online-Shop-Systeme wie Magento liefern Caching-Module direkt frei Haus mit. Eine korrekte Konfiguration ist dennoch kein Kinderspiel und erfordert etwas Geduld. Im Falle des Content Management Systems WordPress lässt sich die Funktionalität über Plugins nachrüsten. Der deutsche Entwickler Sergej Müller bietet hierfür mit Cachify eine hervorragend simple Lösung an.

Zielseiten-Weiterleitungen vermeiden

Die mobile Variante von bundestag.de bietet ein weiteres Beispiel für eine Optimierung der Ladezeit. Ruft man die Domain bundestag.de mit einem Smartphone oder Tablet auf, so wird man gefragt, ob man zur mobilen Variante wechseln möchte. Bejaht man dies, wird man zu erst auf die Domain m.bundestag.de und anschließend auf bundestag.de/mobil weitergeleitet. Im Falle der ersten Weiterleitung könnte man nun über Responsive Webdesign vs. Mobile Site und Usability-Fallstricke im Allgemeinen diskutieren. Die zweite Weiterleitungen ist aber auf jeden Fall unnötig; hier könnte man direkt von bundestag.de auf bundestag.de/mobil springen.

Das sagt PageSpeed Insights zu den Weiterleitungen

Weiterleitungen sollten generell auf ein Minimum beschränkt werden. Denn jede Weiterleitung erzeugt einen eigenen http-Requests, dessen Antwort abgewartet werden muss, bevor das eigentliche HTML-Dokument überhaupt angefordert werden kann. Zudem ist es empfehlenswert, immer direkt mit dem http-location-header zu arbeiten. Eine Weiterleitung auf HTML- oder Javascript-Basis sorgt für weitere Verzögerung, da die kompletten Inhalte quasi doppelt geladen werden müssen.

Fallbeispiel #4: otto.de

Auch am Beispiel des deutschen Online-Shops otto.de lassen sich hervorragend zwei Optimierungstechniken erklären.

Bilder optimieren

Bilder stellen nach wie vor ein prozentual hohen Anteil an der gesamten Dateigröße einer Webseite. Laut httparchive.org waren 2014 durchschnittlich über 50 Bilder auf einer einzigen Webseite eingebunden. Die zu übertragenden Daten durch Bilder legten von 2013 auf 2014 sogar um 21 Prozent zu. Es gibt also gute Gründe – und zum Glück auch viel Potential – um Bilder für das Web hinsichtlich einer schnelleren Ladezeit zu optimieren.

Alleine auf der Startseite von otto.de ließen sich laut Google PageSpeed Insights 156 KB durch eine Optimierung der Bilder einsparen. In Summe werden ca. 900 KB Bildmaterial angefordert, wodurch die prozentuale Ersparnis bei über 17 Prozent liegen würde. Laut similarweb.com hat otto.de 16.900.000 Besucher pro Monat. Würden alleine davon nur 50 Prozent die Startseite besuchen, könnten monatlich über 2,6 Terabyte an übertragenden Daten eingespart werden.

Bilder komprimieren

Bei der Komprimierung von Bildmaterial muss man zwischen zwei verschiedenen Verfahren unterscheiden. Die verlustfreie Komprimierung (lossless) zeichnet sich dadurch aus, dass das Bild in seiner Qualität komplett unverändert bleibt. Ein Reduzierung der Dateigröße ist dennoch durch geschickte Kompression sowie das Entfernen unnötige Meta-Informationen möglich. Hingegen geht die verlustbehaftete Kompression (lossy) noch einen Schritt weiter. So werden beispielsweise Farbwerte ausfindig gemacht, die sich nur sehr marginal unterscheiden und für das Auge kaum sichtbar angeglichen werden können. Dadurch enthält die Bilddatei weniger Informationen und kann besser komprimiert werden.

Ein Bild-Komprimierung ist im kleinen Rahmen problemlos mit Online-Tools wie tinypng.com (für PNGs) oder tinyjpg.com (für JPGs) möglich. Nach dem Hochladen seiner Originaldatei erhält man innerhalb weniger Sekunden eine optimierte Version. Gerade bei PNGs sind Einsparungen bei der Dateigröße höher als 50 Prozent keine Seltenheit. Professionelle Webentwickler können hier wieder einen Schritt weiter gehen und den Komprimierungsprozess in ihren Task Runner integrieren. Für Grunt steht beispielsweise das Imagemin-Plugin zur Verfügung.

Mit tinypng.com und tinyjpg.com sind teilweise erhebliche Einsparungen möglich!

Idealerweise sollte direkt im ersten Schritt überprüft werden, ob das verwendete Bildformat wirklich das beste ist. Gerade bei großen Fotos lässt sich mit JPGs eine wesentlich kleinere Datei erzielen als mit PNGs. Dies ist aber keinefalls in Stein gemeißelt, weshalb eine kurze Überprüfung nie schaden kann.

Bilder in der richtigen Auflösung ausliefern

Ein Problem, welches otto.de ebenfalls betrifft, ist die Auslieferung von Bildern in zu hohen Auflösungen. Beispielsweise werden große Slider-Bilder im Kopfbereich in der Breite von 1920 Pixeln angefordert, obwohl sie auf den meisten Desktop-Rechnern nur mit einer Breite von 960 Pixeln eingebunden werden. Hier werden schnell mehr als hundert Kilobyte umsonst übertragen.

Das Bild auf otto.de wird mit 1920 Pixeln vom Server angefordert, aber nur in einer Größe von 880 Pixeln angezeigt.

Natürlich ist die korrekte Auslieferung von Bildern durch Responsive Webdesign, sehr fluide Layouts und hochauflösende Bildschirme (Stichwort “Retina”) nicht leichter geworden. Doch hier springt seit kurzem das <picture>-Element in die Presche, für das bereits sehr gute Javascript-Polyfills existieren. Dies im Zusammenspiel mit einem Image Server erlaubt auch großen Online-Shops und Webseiten das nahezu pixelperfekte Ausliefern von Bilddaten.

Base64-Zeichenketten verwenden

Gerade bei sehr kleinen und nur einmalig verwendeten Grafiken unter einem Kilobyte macht es meistens Sinn, diese nicht als extra Bilddatei vom Server zu laden. Im Zuge der obersten Pagespeed-Prämisse, http-Requests zu reduzieren, bietet sich eine Einbettung als Data-URL beziehungsweise Base64-Zeichenkette an. Dabei wird die reine Bilddatei quasi base64-kodiert und anschließend als Einzeiler direkt im <img>-Element oder als CSS-Hintergrund eingebunden. So wird zwar das initiale HTML-Dokument oder die CSS-Datei größer, der eingesparte http-Request wiegt dies aber in den allermeisten Fällen wieder auf.

Um Base64-Bilder zu generieren gibt es dutzende Online-Tools wie base64-image.de. Der Profi wird wahrscheinlich eher direkt zu Photoshop-Plugins wie PNG Hat greifen, welches einen direkten Export von Ausschnitten oder einzelnen Ebenen auf Knopfdruck ermöglicht.

CSS-Sprites einsetzen

Auch wenn die guten alten CSS-Sprites in den letzten Jahren durch das Aufkommen von Icon-Fonts oder Retina-Versionen etwas an Bedeutung verloren haben, so sind sie nach wie vor ein solides Werkzeug der Pagespeed-Optimierung. Grob gesagt werden bei dieser Technik mehrere einzelne Grafiken in einer einzigen großen Bildatei platziert. Über ein CSS-Hintergrundbild und die Eigenschaft background-position lassen sich die einzelnen Grafiken dann innerhalb der Bilddatei wieder getrennt ansteuern beziehungsweise im Frontend ausgeben. So sind für ein eigenes Icon-Set von beispielsweise 40 Icons nicht mehr 40 http-Requests notwendig, sondern nur noch ein einziger.

Mit LazyLoading Bilder nachladen

Geschicktes und sauber funktionierendes LazyLoading erfordert bei großen Projekten zwar allerlei technische Raffinesse, kann die Ladegeschwindigkeiten dafür aber auf ein neues Level heben. Dieser Begriff beschreibt die Technik, Bild-Dateien erst vom Server anzufordern, sobald der Benutzer im Begriff ist, sie wirklich zu sehen. In der Regel wird darunter verstanden, dass Bilder, die beim Scrollen in den sichtbaren Bereich (Viewport) gelangen, erst dann geladen werden.

Mit etwas Aufwand lässt sich diese Technik aber noch weiter perfektionieren. Warum sollte beispielsweise ein großer Kopf-Slider bereits beim Seitenaufruf alle zehn Bilder laden und nicht erst das jeweils vorherige oder nächste, sobald der Besucher die Maus über die jeweilige Pfeil-Navigation bewegt hat?

Für kleinere Projekte gibt es hingegen bereits fertige jQuery-Plugins wie unveil.js, die einen unkomplizierten Einstieg in das Thema ermöglichen.

Kritische Ressourcen prioritisieren

Das Prioritisieren von kritischen Ressourcen beziehungsweise das nicht blockierte Laden von above-the-fold-Inhalten stellt sicherlich die Königsdisziplin der Pagespeed-Optimierung dar. Gleichzeitig ist es auch der PageSpeed Insights – Hinweis, der für die meisten Webseiten-Betreiber schier unlösbar scheint. Grob gesagt beschreibt dieser Punkt, dass Javascript- und CSS-Code, der für den sofort sichtbaren Bereich einer Website benötigt wird, auch unmittelbar zur Verfügung stehen sollte. Code, der hingegen nicht kritisch ist, muss in der Lade-Reihenfolge weiter hinten platziert werden oder im Idealfall sogar asynchron, also erst nach dem Laden aller anderen Ressourcen, vom Server angefordert werden.

Was sich in der Theorie erstmal nicht allzu schwierig anhört, stellt selbst erfahrene Webentwickler in der Praxis vor einige Probleme. Zuerst ist auszumachen, was man auf der eigenen Webseite eigentlich unter dem sofort sichtbaren Bereich versteht. Geht man beispielsweise von einem Notebook oder einem 27 Zoll iMac aus? Wie sieht es auf Smartphones oder Tablets aus? Und haben verschiedene Seitentypen nicht auch unterschiedliche sofort sichtbare Bereiche? Eine pauschale Antwort lässt sich hier auf keinen Fall finden. Manchmal darf und muss die Antwort auch sein, an dieser Stelle auf eine weitere Optimierung zu verzichten.

Wer hingegen weniger Probleme bei der Herausarbeitung der sofort sichtbaren Bereiche hat, stößt schnell auf technische Hürden. Eine komplette Zusammenlegung aller CSS- und Javascript-Dateien, wie weiter oben im Artikel empfohlen, funktioniert nun nämlich nicht mehr. Vielmehr müssen die Dateien jeweils in kritisch und nicht kritische Bereich aufgeteilt werden. Gerade bei Javascript-Dateien ist dies leichter gesagt als getan. Funktionalitäten, die das Rendering des sofort sichtbaren Bereiches beeinflussen, müssen hierfür nicht selten in natives Javascript zurückverwandelt werden. Schließlich kann schlecht auf das fertige Laden der großen jQuery-Bibliothek gewartet werden.

Im Falle von otto.de lässt sich dieses Problem gut am ersten Inhaltsbereich “Empfehlungen für Sie” veranschaulichen. Hier werden Inhalte erst nachträglich per AJAX eingefügt. Auch die Funktionalität des Sliders wird über Javascript sichergestellt. Dies bedeutet, dass der Bereich dem Webseiten-Besucher nicht sofort angezeigt werden kann, sobald zuständiges HTML und CSS verfügbar ist. Vielmehr muss darauf gewartet werden, dass die komplette externe Javascript-Datei geladen und ausgeführt wurde. Also spricht man von einer Javascript-Ressource, die das Rendering blockiert.

Zusammenfassend ist zu sagen, dass das Prioritisieren von kritischen Ressourcen zwar das letzte bisschen Ladegeschwindigkeit herauskitzeln kann, Webseiten-Betreiber aber häufig vor enorme technische Herausforderungen stellt. Unter Berücksichtigung aller anderen im Artikel erläuterten Optimierungsmaßnahmen dürfte man sich aber bereits eine sehr solide Basis mit vergleichsweise überdurchschnittlich hoher Ladegeschwindigkeit geschaffen haben.

–
Dieser Artikel wurde am 5. Mai 2015 verfasst. Sämtliche Screenshots und Fallbeispiele wurden zu diesem Datum erfasst.

VG Was…?

Erfahrungsgemäß ist die VG Wort vielen kein Begriff. Deshalb möchte ich an dieser Stelle ein paar Worte darüber verlieren. Die „Verwertungsgesellschaft Wort“ wurde bereits 1958 ins Leben gerufen, um Verlage, aber auch freie Autoren zu unterstützen. Dazu werden bei jedem Verkauf von beispielsweise Druckern, Kopierern, DVD-Brenner oder auch bei der Ausstrahlung von Radio- und Fernsehsendungen Abgaben erhoben.

Diese Abgaben summieren sich pro Jahr immerhin auf einen dreistelligen Millionenbetrag. Zwischen allen Verlagen und Autoren, die sich aktiv bei der VG Wort angemeldet haben, wird der eingenommene Betrag Jahr für Jahr aufgeteilt. Und zwar zu fairen Anteilen nach Leser- bzw. Besucherzahlen getrennt.

Das spannende für uns #Neuländler: Auch mit einer oder mehreren Webseiten kann man sich bewerben. Wer also sowieso schon Banner- oder Affiliate-Werbung auf seinem Blog schaltet und über solide Besucherzahlen verfügt, für den kann sich eine Anmeldung bei der VG Wort durchaus auszahlen. Verfügt man beispielsweise über 100 Artikel, die im Kalenderjahr mindestens 1.500 mal aufgerufen wurden und mehr als 1.800 Zeichen haben, so ist bereits mit vierstelligen Einnahmen zu rechnen.

Mehr zur VG Wort findet ihr unter anderem auf Selbständig im Netz…

WordPress Plugin

Da der Einbau der VG Wort Zählpixel nicht immer ganz trivial ist, habe ich mir, wie anfangs bereits erwähnt, für ein eigenes News-Projekt ein WordPress Plugin geschrieben. Die verfeinerte Version dessen möchte ich euch hier gerne zum Download bereitstellen:

Plugin herunterladen

 1.) Plugin installieren

Nachdem ihr das Plugin-Archiv frisch heruntergeladen habt, könnt ihr es entweder entpacken und dann per FTP auf den Server laden oder alternativ direkt über den WordPress ZIP-Auswahldialog hochladen. Anschließend muss das Plugin nur noch aktiviert werden und der Spaß kann beginnen.

 2.) Neue Zählmarken bestellen und Plugin konfigurieren

In der WordPress-Seitenleiste dürfte nun der neue Menüpunkt VG Wort erschienen sein. Klickt ihr diesen an, landet ihr im Optionspanel des Plugins. Hier sollten nun die ersten Zählpixel hinterlegt werden…

Auf dieser Seite könnt ihr (falls bei VG Wort angemeldet) neue Zählmarken bestellen. Dazu tragt als erstes einen Wert zwischen 1 und 100 in die Eingabemaske ein.

Die nachfolgende Seite ist für die Erstkonfiguration des Plugins ebenfalls sehr wichtig. Hier findet ihr nämlich eure Zähldomäne. Dies ist quasi der eindeutig mit eurem Konto verknüpfte VG Wort -Server. Für die Lauffähigkeit des Plugins ist es essentiell, dass ihr die angezeigte Domain im Konfigurationsmenü des Plugins eintragt.

3.) Bestellte Zählmarken hinterlegen

Ist die Zähldomäne korrekt hinterlegt, so können als nächstes die bestellen Zählmarken in das Plugin eingepflegt werden. Dieser Schritt kann beliebig wiederholt werden. Natürlich kann man direkt zu Beginn 500 Zählmarken hinterlegen oder immer bei Bedarf nachpflegen. Sinkt die Anzahl der noch freien Zählmarken unter 10, so weist das Plugin prominent darauf hin.

Nachdem man die von der VG Wort generierte CSV-Datei mit den Zählmarken heruntergeladen hat, öffnet man sie mit einem Tool seiner Wahl (z.B. Excel, OpenOffice Calc oder Google Drive). Man sollte folgende Ansicht erhalten:

Nun kopiert man zuerst sämtliche Datensätze aus der linken Spalte (ohne Überschrift) und fügt sie im Plugin in die Textbox mit der Überschrift Öffentlicher Identifikationscode ein. Die rechte Spalte kommt dementsprechend unter Privater Identifikationscode. Kurz überprüfen und anschließend auf Importieren klicken.

Ist alles glatt gelaufen, sollte man nun unten eine Übersicht der verfügbaren Zählmarken sehen. Natürlich kann man sich hier von Zeit zu Zeit auch einen Überblick verschaffen, wie viele Zählmarken noch frei sind.

4.) Plugin arbeiten lassen

Dieser Part ist der einfachste, denn aktiv muss man nun nichts mehr tun. Jedesmal, wenn man einen neuen Beitrag veröffentlicht, werden diesem automatisch aus dem Pool der noch freien Zählmarken ein Pärchen aus öffentlichem und privatem Code zugeordnet. Technisch gesehen passiert dies auf Basis der beiden Custom Fields vgwort-private und vgwort-public.

Auch das Einfügen des Zählpixels im Frontend in Form eines 1×1 Pixel großen Bildes geschieht vollautomatisch. Dazu wird bei der Ausgabe eines Artikels auf den WordPress-Filter the_content zugegriffen.

Wer das Plugin nutzen möchte und auch alte Artikel mit Zählpixeln nachrüsten will, der kann die beiden Custom Fields vgwort-private und vgwort-public in den jeweiligen Artikeln  manuell setzen.

5.) Zählmarkenrecherche

Wer bereits mit der VG Wort gearbeitet hat, der wird es kennen: Einmal im Jahr erhält man eine E-Mail, dass nun die Zählmarken aus dem Vorjahr abgerechnet werden können. Dazu stellt die VG Wort eine Übersicht der Zählpixel bereit, die jeweils den Mindestzugriff an Besuchern erreicht haben. Was danach kommt, ist eine extrem nervige und friemelige Arbeit.

Auch hier möchte das VG Wort WordPress Plugin einiges an Arbeit abnehmen. Unter dem Menüpunkt Zählmarkenrecherche stellt es nämlich eine Funktion zur Verfügung, mit der man sowohl nach öffentlichen als auch privaten Zählmarken suchen kann. Hier trägt man nun in der Regel den in der VG Wort Übersicht angezeigten privaten Code ein und erhält nach einem Klick auf Suchen detaillierte Informationen zum entsprechenden WordPress-Artikel. Diese Übersicht ist so eingerichtet, dass die wichtigsten von der VG Wort abgefragten Eigenschaften direkt ausgegeben werden, z.B. Artikel-Titel, Autor, Anzahl der Zeichen, …

Plugin herunterladen

Mehr muss an dieser Stelle gar nicht gesagt werden. Wem das Plugin gefällt, darf diesen Beitrag sehr gerne plussen, liken, tweeten, teilen und natürlich verlinken :-)

Updates

Version 1.1

Die Version 1.1 ist am 17. Januar 2014 erschienen und bietet die folgenden Verbesserungen:

• Einige Nutzer berichteten von kritischen Fehlern, die das Plugin unbenutzbar machten. Diese sollten nun behoben sein.
• In den globalen Optionen lässt sich nun ein Zeichen-Limit einstellen. So werden Beiträge, die unter diesem Limit bleiben, erst gar nicht mit einem Zählpixel versorgt. Erweitert man solche Beiträge später um zusätzlichen Inhalt, wird nachträglich ein Zählpixel hinzugefügt, sobald genügend Zeichen vorhanden sind.
• Beim Importieren neuer Zählmarken lässt sich nun festlegen, ob die Marken für das gesamte Projekt oder nur einen einzelnen Nutzer hinzugefügt werden sollen. Auf diesem Weg kann man für einzelne Autoren individuelle Zählmarken hinterlegen.
• Beim Importieren neuer Zählmarken lässt sich nun zudem eine optionale Zähldomäne angeben. Diese Domäne wird dann nur für die neu hinzugefügten Zählmarken verwendet. Dies ist beispielsweise beim Einsatz der Autoren-Funktion notwendig, da sich die Zähldomänen von unterschiedlichen VG Wort Konten unterscheiden können.
• Hinzugefügte, aber noch nicht genutzte Zählmarken können nun aus der Übersicht heraus gelöscht werden.
• Es wurde eine Übersicht hinzugefügt, die die bereits verteilen Zählmarken auflistet. So erhält man einen schnellen Überblick und kann sich auf Wunsch weitere Details anzeigen lassen.

Wünsche & Feature-Requests?

Ihr habt noch eine Idee, wie ich das Plugin sinnvoll erweitern kann? Lasst es mich gerne in den Kommentaren wissen! :-)

Für mich wird es in diesem Jahr die erste Teilnahme sein. Ich hatte die Chance, eines der wenigen Blogger-Tickets zu einem reduzierten Preis zu ergattern. Das bedeutet, ich werde euch vor, nach und vor allem während der Konferenz mit spannenden Infos rund um die Vorträge und das Event versorgen. Am besagten Donnerstag und Freitag dürfte es also auf meinen sozialen Profilen etwas aktiver werden :-)

Was erwartet die Besucher?

In erster Linie hoffentlich extrem spannende Vorträge rund um das Thema Webentwicklung. Die nackten Fakten sprechen für sich: Auf 1.500 Teilnehmer kommen 120 Speaker in zwölf Tracks: Big Data (21), E-Commerce (4), IT Management (25), Infrastructure (33), Java (23), JavaScript (14), Mobile (10), New Technology (23), PHP (8), Ruby (3), Skalierung (16), und UX/Frontend (8).  Davon werden 90 Vorträge in deutscher Sprache gehalten, 18 auf Englisch.

Unter den Speakern befinden sich unter anderem ein Javascript-Entwickler von Facebook, ein Google-Entwickler, ein Team-Leiter bei eBay oder auch ein Programmierer von Stack Overflow. Natürlich findet man unter den Vortragenden auch viele Selbständige, Freiberufler oder Unternehmer, deren Vortragsthemen nicht minder spannend klingen.

Das Besondere? Die Location!

Ohne jemals auf der Developer Conference bzw. der code.talks gewesen zu sein, glaube ich, dass die Veranstalter eine sehr spezielle Location gefunden haben. Das Cinemaxx Hamburg-Dammtor lockt mit acht riesigen Kinosälen, bequemen Kinosesseln und all inclusive Popcorn – genial!

Abgerundet wird die Location natürlich durch die Tatsache, dass auf den großen Kinoleinwänden kein Detail des Vortrages verloren geht. Flächendeckendes WLAN und klimatisierte Räume tragen weiterhin zum Wohlbefinden der Konferenz-Teilnehmer bei.

Ich bin gespannt…

Ich blicke also gespannt auf die beiden Tage in Hamburg und freue mich in insgesamt 14 Vorträgen viel neues Wissen mitzunehmen. Für die folgenden habe ich mich übrigens entschieden:

• Build your own Event-Tracking: Messung und Analyse des Benutzerverhaltens in sehr großen Internet-Systemen zur Optimierung der User Experience
• Optimierung der User Experience einer Mobilanwendung mit Machine Learning
• Agiler Responsive Workflow
• 10 lessons learned while growing from 1 to 1000
• Der Code zum Erfolg
• Fragmented Web Design
• OnConnectionLost: Das Leben einer Offline Web-Applikation
• WebAPI – expand what the Web can do today
• Entwicklung eines Entwicklers – Was kommt nach dem entwickeln?
• Modern Web Application (In-)Security
• Mit offener Kommunikation Projekte meistern
• Was nicht passt wird responsive gemacht
• Projekt Code University – Warum ich an einer modernen Ausbildung für Entwickler arbeite
• E-Commerce Systeme gestern, heute und morgen

Wie gesagt werde ich euch die beiden Tage über via Social Media und im Anschluss an die Konferenz über meinen Blog auf dem Laufenden halten!

Seit wenigen Stunden ist nun auch das dritte große Soziale Netzwerk, Google+, mit von der Partie. Ähnlich wie bei den Facebook Beiträgen lassen sich auch Google+ Posts mit Hilfe eines kurzen Code Snippets in jeder beliebigen externen Webseite anzeigen. Dabei gelten ungefähr die selben Richtlinien wie beim blauen Konkurrenten: Beiträge, die nur mit bestimmten Kreisen, also nicht öffentlich, geteilt wurden, können logischerweise nicht eingebettet werden.

So sieht ein eingebetteter Google+ Post aus

Hier ein kurzes Beispiel, wie ein eingebundener Beitrag aussehen könnte:

[gp-post href=“https://plus.google.com/114421677831789165567/posts/5SLVJraiZ4P“]

Was ist zu beachten?

Möchte man Google+ Beiträge auf seiner Webseite oder Blog einbetten, muss man einige Richtlinien beachten. Beispielsweise muss die verwendete Post-URL korrekt sein, da es hier unterschiedliche Varianten gibt.

Korrekt ist:

• https://plus.google.com/110174288943220639247/posts/cfjDgZ7zK8o

Nicht korrekt ist:

• https://plus.google.com/+LarryPage/posts/MtVcQaAi684
• https://plus.google.com/u/0/106189723444098348646/posts/MtVcQaAi684

Außerdem gibt es Stand heute einige Einschränkungen hinsichtlich der verwendbaren Formate.

In Ordnung sind:

• Beiträge mit Bildern
• Beiträge mit Videos
• Beiträge mit Links zu einer Community

Nicht in Ordnung sind:

• Beiträge innerhalb einer Community
• Beiträge, die auf eine Google Apps Domain beschränkt sind
• Private Beiträge
• Event Beiträge
• Hangout on Air Beiträge

Die Google+ Embedded Posts verwenden

Wie bereits eingangs geschrieben, stellt Google Webseitenbetreibern ein kleines Code Snippet zur Verfügung, um die Beiträge auf der eigenen Webseite einzubetten. Dies ist vergleichbar mit dem Einbau des +1 Buttons. In der Google Entwicklerdokumentation findet man hierzu einen englischsprachigen Hilfe-Artikel.

So könnte es beispielsweise in der Praxis aussehen:

WordPress Plugin zum schnellen Einbetten

Wer WordPress als CMS oder Blogsystem einsetzt, kann sich hier direkt das (hoffentlich erste) Google+ Embedded Posts WordPress Plugin herunterladen.

Das Einbetten der Beiträge geht damit noch schneller von der Hand. Nach der Aktivierung steht euch in Artikeln und Seiten der Shortcode gp-post zur Verfügung, an den ihr den Parameter href übergeben könnt. Hier einmal ein vollständiges Beispiel, dass die Funktionsweise recht gut veranschaulichen sollte:

An die benötigte URL kommt man übrigens sehr einfach, in dem man bei einem Beitrag auf den jeweiligen Zeitstempel klickt. Nun öffnet sich der Post in einem neuen Tab und ihr könnt die URL aus der Browser-Adresszeile kopieren. Aber wie gesagt darauf achten, dass der Beitrag den Richtlinien entspricht bzw. öffentlich ist.

Aktuell könnt ihr das Plugin von meinem Server oder von GitHub herunterladen. Anschließend den entpackten Ordner in euer WordPress Plugin Verzeichnis hochladen und über das Backend aktivieren.

Plugin direkt herunterladen

Plugin auf GitHub

Im Facebook HQ wird man sich gedacht haben, dass die Möglichkeit, Facebook Beiträge zu integrieren für den ein oder anderen Webseiten-Betreiber ebenfalls interessant sein dürfte. Prinzipiell folgt man auch hier einem einfachen Schema. Alles was zum Einbinden benötigt wird ist ein kurzes Code Snippet so wie die URL des jeweiligen Facebook Posts. Einen kleinen Haken hat die Sache dann aber doch; ähnlich wie bei Twitter können natürlich nur öffentlich gepostete Beiträge angezeigt werden. Bei Facebook werden aber mittlerweile (zum Glück) die meisten privaten Nachrichten nicht mehr öffentlich, sondern nur im begrenzten Rahmen geteilt. Vorwiegend dürfte die neue Funktion zum Einbetten von Posts also genutzt werden, um die Beiträge von Facebook (Unternehmens-) Seiten zu teilen. Diese posten nämlich logischerweise fast immer öffentlich.

Beispiel gefällig?

Hier mal ein kurzes Beispiel, wie das ganze aussehen könnte:

[fb-post href=“https://www.facebook.com/torbenleuschner.de/posts/568421526533431″]

WordPress Plugin herunterladen

Ich habe mir gedacht, es wäre ganz nett, wenn Blogger und Webseitenbetreiber direkt zum Start der neuen Facebook Funktion ein WordPress Plugin zur Verfügung hätten, mit dem sie schnell und einfach die Beiträge in Artikeln oder Seiten integrieren können. Und hier ist es, ein WordPress Plugin zum Einbetten von Facebook Posts mit dem Namen Facebook Embedded Posts.

Das Einbinden ist denkbar simpel. Über den Shortcode fb-post und den dazugehörigen Parameter href lässt sich die Funktion innerhalb von WordPress Artikeln, Seiten oder Widgets beliebig nutzen. Hier ein vollständiges Beispiel:

Wer übrigens noch nicht weiß, wie man an die URL zu einem Facebook Beitrag kommt, auch dies ist schnell erklärt. Unter jedem Beitrag findet ihr immer eine verlinkte Zeitangabe (z.B. „vor 4 Minuten“). Bei einem Klick auf diese öffnet sich der Beitrag unter der jeweiligen URL in einem eigenen Tab.

Das Facebook WordPress Plugin könnt direkt von meinem Server herunterladen. Die gezippte Datei muss lediglich entpackt und der Ordner anschließend in das plugin Verzeichnis eurer WordPress Installation verschoben werden. Alternativ könnt ihr es auch direkt über das offizielle WordPress Plugin Verzeichnis laden oder von dort direkt installieren.

Plugin direkt als ZIP-Datei herunterladen

Plugin im WordPress Plugin-Verzeichnis

Ich möchte heute an dieser Stelle nicht der Frage nachgehen, ob und wann eine Single Page einer Variante mit mehreren Unterseite vorzuziehen ist oder welche Vor- und Nachteile im Bezug auf die Suchmaschinenoptimierung entstehen. Vielmehr möchte ich etwas in den Bereich Online Marketing und Besucher-Tracking abdriften.

Kein Google Analytics? Keine Informationen zum Besucherverhalten!

Viele Entscheider wird es wahrscheinlich abschrecken, dass man bei Single Pages keine echten Informationen über das Besucherverhalten erhält. Zwar kann man Google Analytics oder ein vergleichbares Tool natürlich einbetten, bekommt dann aber nur Kennzahlen über Verweildauer oder Absprungrate angezeigt.

Dabei wäre es für den Seitenbetreiber doch viel interessanter zu erfahren, wie der Nutzer auf der Seite scrollt, ob zum Beispiel das Kontaktformular angezeigt wird oder an welcher Stelle die meisten Nutzer die Seite verlassen. Gerade der letzte Punkt bietet eine hervorragende Möglichkeit, nach und nach die größten Schwachstellen auf der Single (Landing) Page zu identifizieren und zu optimieren.

Simples Script zum Erfassen des Scroll-Verhaltens

Die gute Nachricht: Das Erfassen des Scroll-Verhaltens der Nutzer ist nicht so komplex wie vielleicht vermutet. Auf Basis des jQuery-Frameworks und der Analytics Methode _gaq.push() habe ich ein kleines Script vorbereitet, welches ihr mit minimalem Anpassungen auf euren Single Pages verwenden könnt:

HTML-Quellcode im Detail

Der obere Abschnitt zeigt das stark vereinfachte HTML-Dokument der Single Page. Hier gibt es nicht besonders viel zu erklären. Von Zeile 7 bis 17 wird der normale Google Analytics Code eingebunden. Neben einigen kleinen CSS-Formatierungen von Zeile 19 bis 27 binden wir in Zeile 46 noch das jQuery-Framework in der aktuellsten Version ein. Eine Zeile dadrunter laden wir dann die script.js, in der die eigentliche Arbeit verrichtet wird.

Wichtig ist nur, dass man den Aufbau der section-Elemente versteht. Dies können natürlich auch div oder article – Elemente sein, wichtig ist nur, dass die Abschnitte auf eurer Single Page, die später getrackt werden sollen, auch über eindeutige Klassen verfügen. In unserem Beispiel sind das section-a, section-b, section-c und section-d.

Javascript-Quellcode im Detail

Nun gucken wir uns die script.js im Detail an:

• Zeile 1
  Wir verwenden die jQuery document.ready()-Funktion um sicherzustellen, dass das DOM komplett zur Verfügung steht.
• Zeile 2
  Wir initialisieren eine leere Variable, in der wir später speichern, welcher Bereich auf der Single Page zuletzt angezeigt wurde. Dies ist wichtig, damit später nicht bei jedem Scrollen innerhalb eines Bereiches ein neuer Pageview an Google Analytics übermittelt wird.
• Zeilen 3 bis 8
  Dieses Javascript-Objekt ist theoretisch der einzige Bereich, den ihr bei Verwendung des Script auf eure Bedürfnisse anpassen müsst. Die jeweiligen Schlüssel (z.B. section-b) stehen dabei für die Klassen der Elemente im HTML-Dokument. Die zugehörigen Wert (z.B. /bereich-b) bezeichnen hingegen die URL, welche als Pageview an Google Analytics übermittelt wird. Hier könnte man beispielsweise auch /kontakt.html eintragen, wichtig ist aber das führende „/„. Außerdem sollte das im HTML-Dokument letzte Element im Objekt zuerst genannt werden und so weiter.
• Zeilen 28 bis 29
  Ein kleiner Sprung innerhalb des Dokuments. An dieser Stelle rufen wir anfangs die Funktion scrollTrackPageview() direkt auf. Dies ist empfehlenswert, um direkt zu Beginn die Variable tracking_active korrekt zu setzen. In Zeile 29 weisen wir den Aufruf der Funktion dem jQuery scroll-Event zu. Somit wird bei jedem Scroll-Vorgang des Nutzers unsere Funktion scrollTrackPageview() aufgerufen.
• Zeilen 11 bis 17
  Innerhalb dieser Schleife gehen wir das tracking-Objekt durch und überprüfen, ob sich der Viewport aktuell auf dem entsprechenden Bereich befindet. Dazu nutzen wir die beiden jQuery-Funktionen scrollTop() und offset(). Das Ergebnis in Form der Pageview-URL speichern wir in der Variablen section.
• Zeilen 19 bis 20
  An dieser Stelle überprüfen wir, ob die section-Variable korrekt ermittelt wurde und ob deren Wert ungleich mit tracking_active ist. Falls nicht, wird die Ausführung der weiteren Funktion unterbrochen und es passiert nichts.
• Zeile 22
  Die wohl wichtigste Zeile. Wir werden _gaq.push() um den „virtuellen“ Pageview an Google Analytics zu übermitteln.
• Zeile 23
  Wer die korrekte Funktionsweise des Script überprüfen möchte, kann diese Zeile entkommentieren. Dann wird bei jedem Aufruf von _gaq.push() auch ein Eintrag in die Browser-Konsole geschrieben.

Bonus 1: Pageview beim Abschicken eines AJAX-Kontaktformulares

Natürlich könnt ihr auch andere Events auf diese Weise erfassen, beispielsweise das Abschicken eines Kontaktformulares oder einer Registrierung per AJAX. Dies bietet sich vor allem an, um die Konversion-Rate des Vorgangs zu erfassen.

Im folgenden der diesmal unkommentiere Quellcode. Wer den Vorgang in der script.js verstanden hat, wird hiermit auch zurecht kommen ;-)

Bonus 2: Bestimmte Events in Google Analytics als Konversion kennzeichnen

Mit Google Analytics ist es sehr leicht möglich, aus den aufgezeichneten Pageviews ein simples Konversion-Tracking zu erstellen. Dazu wechselt man in der Analytics Navigation auf den Punkt „Conversions“, dann „Ziele“, dann „Übersicht“ und dann auf „Ziele definieren“. Hier nun ein weiterer Klick auf „Ziel erstellen“.

Den Namen des neuen Ziel kann man natürlich frei wählen, wie zum Beispiel „Kontaktformular abgeschickt“. Unter der Auswahl „Typ“ wählt man schließlich „Ziel“ aus.

Im nächsten Schritt trägt man nun unter „Ziel“ den URL-Part genau so ein, wie wir in vorhin im Script definiert haben. Also z.B. /section-b. Optional kann man noch Werte oder Trichter zuweisen und mit einem Klick auf „Ziel erstellen“ wurde das Konversion-Tracking auch schon angelegt.

Das ganze funktioniert natürlich wie erwähnt nicht nur für Events wie das Abschicken eines Formulares, sondern es kann auch ein Konversion-Tracking für das Scrollen an einen bestimmten Punkt aufgesetzt werden.

Ich hoffe der Beitrag hat euch gefallen. Falls etwas unverständlich ist, nutzt einfach die neue Google+ Kommentarfunktion :)

Google schreibt dazu folgendes:

Eure Blog-Leser haben nun die Möglichkeit, ihre Kommentare für alle oder nur für ihre Kreise auf Google+ zu veröffentlichen. Beim Durchlesen können die Leser außerdem festlegen, ob sie alle Kommentare, nur die neuesten oder nur die von Personen aus ihren Kreisen sehen möchten.
Generell gilt, dass ihr und eure Leser jeweils nur die Kommentare sehen können, für die eine Berechtigung vorliegt. Damit wird nicht nur ein gezielteres Teilen von Inhalten und Kommentaren ermöglicht, sondern potenziell auch mehr Traffic zu eurem Blog generiert.

Laut diversen Quellen befindet sich die Google+ Kommentarfunktion bislang noch in einer Testphase und wurde deshalb auch nur für den Blogger-Dienst freigeschaltet. Wer ein bisschen technisches Verständnis hat, wird aber schnell feststellen, dass die Einbettung der Kommentare über einen simplen iframe (nach dem ähnlichen Schema wie bei Facebook) erfolgt. An die einzubettende Google-Seite wird die URL übergeben, zu der die Kommentare gespeichert werden sollen.

Google+ Kommentare in Aktion auf einem Testprojekt

Wie baue die die Google+ Kommentare auf meiner Webseite ein?

Die gekürzte Google-URL lautet wie folgt:

https://plusone.google.com/_/widget/render/comments?href=[URL]

Somit ist es also möglich, die Google+ Kommentare bereits heute ohne großen Aufwand oder speziellem Hack auf der eigenen Seite zu verwenden. Folgender Quellcode zeigt die statische Implementierung, als auch den Einbau in WordPress oder fokus:

Über die Parameter width und height lassen sich die Dimensionen des Kommentar-Widgets anpassen. Dabei ist mir aufgefallen, dass der innerhalb der Google-URL übergebene Wert ca. 50 Pixel kleiner sein sollte als die iframe-Breite, um Scrollbalken zu vermeiden. Per hl-Attribut definiert man die zu verwendende Sprache, also zum Beispiel „de“ für Deutsch.

In meinen Tests gab es keinerlei Schwierigkeiten bei der Verwendung des Google+ Kommentar-Widgets. Es ist davon auszugehen, dass Google eine frühzeitige – wenn auch nicht offizielle – Einbettung toleriert. Durch Veröffentlichung der entsprechenden URLs beziehungsweise des iframe-Snippets im Quellcode des Blogger-Dienstes war davon auszugehen, dass es nur eine Frage der Zeit ist, bis die Funktion in externen Webseiten auftaucht.

WordPress Plugin für Google+ Kommentare

Schnell, schneller, André Goldmann. Er hat die Gunst der Stunde genutzt und bereits ein WordPress Plugin für Google+ Kommentare veröffentlicht! :)

Vor ziemlich genau anderthalb Jahren, also noch vor Panda, behauptete ich im Artikel „Vorteile von HTML5 aus SEO-Sicht“, dass moderne Webseiten in Zukunft Vorteile beim Suchmaschinen-Ranking erfahren könnten. Damals erhielt ich natürlich viel Gegenwind, schließlich waren Links das Maß aller Dinge. Im letzten Jahr scheint sich die Situation aber etwas gewandelt zu haben und Onpage Optimierungen werden (zum Glück) wieder wichtiger.

Responsive Webdesign

Für alle Leser, die noch nichts mit dem Begriff anfangen können, möchte ich die Technologie kurz beschreiben. Responsive Webdesign beschreibt Techniken um die Ausgabe des Inhalts an die Eigenschaften des Ausgabegerätes anzupassen. In der Regel geht es dabei um die Skalierbarkeit einer Website auf Basis der verfügbaren Pixel.

Die technische Basis hinter Responsive Webdesign bilden die CSS3 Media Queries. Diese sind quasi so etwas wie IF-Abfragen im CSS-Quellcode. Viele wissen nicht, dass diese Media Queries noch mehr können, als nur die Bildschirmdimensionen zu verrechnen. So lässt sich beispielsweise auch ermitteln, ob das Endgerät in der Lage ist, einen Hover-Status zurückzuliefern. Für Mouseover-Navigationen eine wichtige Information.

Im OnlineRadar meine ich herausgehört zu haben, dass Responsive Webdesign durch den Begriff „Mobile“ geprägt ist. Das würde ich so nicht unterschreiben. Der große Vorteil der neuen Technologie liegt gerade in der Unabhängigkeit von Gerätekategorien.

Inhalte werden für den Nutzer passend ausgeliefert. Das betrifft nicht nur Smartphones, sondern auch Tablets, Notebooks, TV-Geräte und sogar den 27 Zoll iMac.

Bessere Rankings für responsive Webseiten? Ja, bitte!

Meiner Meinung nach gehört Responsive Webdesign zu den im Bezug auf Suchmaschinenoptimierung wichtigsten technologischen Entwicklungen der letzten Jahre. Die These stützt sich auf die Prämisse Googles, zu einem Suchbegriff das beste Ergebnis im Web anzuzeigen. Doch warum könnte sich diese Korrelation in den letzten Jahren verschoben haben?

Zugegeben, am 27 Zoll iMac mit 100.000er Leitung sitzend, kann es dem Suchenden so ziemlich egal sein, ob die Website 100 oder 500 KB laden muss. Ebenso ist es ihm schnuppe, ob der Inhaltsbereich 1200 Pixel breit ist. Und noch weniger interessiert es ihn, ob er die Subnavigation nur per Mouseover erreichen kann. Er findet die Information die er sucht.

Selbe Suche; andere Situation. Statt daheim im warmen zu sitzen, könnte der Suchende ja gerade auch unterwegs sein. Den iMac hat er ausnahmsweise Zuhause gelassen und stattdessen nur sein iPhone dabei. Natürlich ist LTE nicht verfügbar; EDGE muss ausreichen.

Ist unter diesen Umständen die beschriebene Webseite dann wirklich noch das beste Ergebnis?

Google liebt Responsive Webdesign

Google selbst gibt offen zu, Responsive Webdesign als beste Lösung für mobile Webseiten zu sehen. Folgenden Auszug (frei durch mich übersetzt) findet man auf der offiziellen Google Doku-Seite „Building Smartphone-Optimized Websites„:

Wir empfehlen den Einsatz von Responsive Webdesign, da es mehrere positive Aspekte vereint:

• Die Verwendung von nur einer einzigartigen URL für denselben Inhalt macht es Benutzern einfacher, den Inhalt über soziale Netzwerke zu teilen oder die Seite zu verlinken. Außerdem ist es für den Google Crawler leichter, die Seite korrekt zu indexieren.
• Es ist keine Weiterleitung nötig, um den Nutzer auf die mobile Webseite zu bringen. Weiterleitungen beinträchtigen die Ladezeit negativ und können in vielen Fällen, vor allem bei Weiterleitungen auf Basis des User Agents, zu Fehlern führen.
• Es werden sowohl für dich als auch für den Google Crawler Ressourcen eingespart. Der Google Bot muss deine responsive Webseite nur ein einziges Mal besuchen, um an den Content zu kommen. Deshalb können wir effizienter Crawlen und deine Seite somit auch häufiger besuchen.

Interessant in dem Zusammenhang ist auch die Frage, ob Google optimierte Webseiten bereits erkennt. Auch zu diesem Thema findet man eine klare Stellungnahme (wieder frei durch mich übersetzt):

Stell sicher, dass der Googlebot wichtige Seitenbestandteile wie Bilder, CSS- und Javascript-Dateien korrekt crawlen kann. Diese dürfen nicht über die robots.txt oder anderweitig blockiert werden. Wenn wir in der Lage sind, auf diese externen Dateien zuzugreifen, kann unser Algorithmus deine responsive Webseite korrekt verarbeiten.

Praxistest bringt Erkenntnis

Gerade durch den Siegeszug der (günstigen) Tablets im letzten Jahr sind sehr viele Menschen mit dem Medium Internet in Berührung gekommen, die man nicht gerade als affin bezeichnen kann. Wie sich diese Entwicklung im Jahr 2013 weiterführen wird, dürfte klar sein.

Macht selbst den Praxistext. Gebt einer Person aus diesem Umfeld die Anweisung, auf zwei verschiedenen Webseiten nach Informationen zu suchen. Auf der einen Seite die klassische Desktop Website, auf der anderen Seite die für sein Endgerät optimierte Webseite. Welche wird wohl in seiner Gunst vorne liegen? Die auf der er erst pinchen, zoomen und scrollen muss? In den seltensten Fällen!

Warum sollte Google das anders sehen?

Schreiben möchte ich mal wieder über eines meiner aktuellen Lieblingsthemen: Pagespeed. Bereits vor einigen Monaten habe ich hier auf dem Blog einen relativ umfangreichen Artikel zum Thema Pagespeed veröffentlicht, der auf mehrere einzelne Teilaspekte eingeht. Heute möchte ich etwas konkreter werden und mich einem Thema zuwenden, mit dem sich wohl jeder Webmaster schon mal rum geärgert hat. Die Rede ist von den bekannten Social Buttons (Facebook, Twitter, Google +1), auf die man zum einen selten verzichten möchte, die auf der anderen Seite aber häufig ein Grund für schlechte Website-Performance sind.

Lösung: Erst das Wichtige laden lassen

Technisch gesehen gibt es für dieses Problem eine recht simple Lösung, die sich sogar ohne den Einsatz von Javascript-Bibliotheken wie jQuery schnell umsetzen lässt. Wir warten einfach ab, bis die wichtigen Bestandteile der Website (CSS, Bilder, Javascript, …) geladen sind und geben anschließend erst die Anweisung, die Social Buttons zu integrieren.

Schauen wir uns dazu einfach mal ein stark vereinfachtes HTML-Dokument an:

Sieht auf den ersten Blick wahrscheinlich komplizierter aus als es ist. Folgend möchte ich euch die wichtigen Passagen des Dokuments im Detail erklären:

• Zeilen 5 – 10:
  Hier nehmen wir eine ganz einfache Formatierung für die Social Buttons vor. Sie sollen sich linksbündig anordnen und 12 Pixel Abstand zum nächsten Button einhalten.
• Zeile 16:
  An dieser Stelle initialisieren wir einen leeren DIV-Container mit der ID social-buttons. In diesen fügen wir im Anschluss per Javascript die Buttons ein.
• Zeile 19:
  Per window.onload sagen wir der anonymen Funktion, dass sie mit der Ausführung warten soll, bis die komplette Website (einschließlich Bildern) vollständig geladen wurde. Somit wird an dieser Stelle bereits verhindert, dass das Laden der Social Buttons den Aufbau der restlichen Website behindert.
• Zeilen 20 – 22:
  Die Social Buttons benötigen eine URL, auf die sie sich beziehen können. Twitter benötigt zudem noch einen Titel beziehungsweise Tweet-Text. Diese Angaben könnte man zwar auch leer lassen und die Buttons würden sich automatisch URL und Seitentitel ziehen; ich empfehle jedoch immer eine manuelle Eingabe vorzunehmen, um Fehlerquellen im Vorfeld auszuschließen.
  In Content Management Systemen wie WordPress oder fokus stehen zum Füllen dieser Variablen praktische Funktionen bereit. Für die URL wäre das the_permalink() beziehungsweise $fks->getURL() und für den Titel the_title() beziehungsweise $fks->getTitle().
• Zeile 24:
  Wir referenzieren das DIV  #social-buttons für den späteren Aufruf.
• Zeile 26:
  Neben window.onload kommt auch noch die Funktion setTimeout() zum Einsatz. Damit können wir den Aufruf der folgenden anonymen Funktion um eine gewünschte Anzahl von Millisekunden aussetzen (Variable wait in Zeile 22 und 49).
  So stellen wir zum einen sicher, dass die Website wirklich fertig geladen ist. Zum anderen gibt es Artikel die ich auf die schnelle nicht finde, dass die Conversion Rate der Buttons besser sei, wenn sie nicht sofort sichtbar sind sondern erst nach einiger Zeit erscheinen.
• Zeilen 28 – 30:
  An dieser Stellen fügen wir das HTML des Twitter Buttons in unser bis dato noch leeres DIV ein. Das legen wir uns als erstes ein neues DIV an (Z. 28), welches wir anschließend (Z. 29) mit Inhalt befüllen. Hier finden wir auch die Variablen url und title wieder, die wir an entsprechender Stelle einsetzen. In Zeile 30 fügen wir unser neues DIV schließlich in unser Bestehendes (#social-buttons) ein.
• Zeile 32:
  Hier laden wir nun das zum Twitter-Button gehörende Javascript. Dieses stammt nicht von uns sondern wurde einfach von der entsprechenden Tweet-Button-Dokuseite entnommen.
• Zeilen 35 – 40:
  Nun wird auch der Google +1 Button geladen und in die Seite integriert. Die Ausführung ist mit der des Tweet-Buttons nahezu identisch. Das Javascript in Zeile 40 wurde von der +1-Dokuseite kopiert.
• Zeilen 43-48:
  Das beste kommt zum Schluss? In diesem Fall nicht ganz richtig, schließlich ist der Facebook Like Button in jeder Hinsicht einfach nur grausig. Nachgeladen lädt der Button an sich zwar auch nicht schneller, aber er bremst den restlichen Seitenaufbau wenigstens nicht aus.
  Wie bei den anderen beiden Buttons zuvor wurde das Javascript in Zeile 48 wieder nur kopiert; und zwar von hier.

Keine Abstriche bei der Individualisierung der Buttons

Getestet habe ich das ganze erfolgreich mit dem Facebook, Google +1 und Tweet-Button. Im Prinzip sollte es aber auch mit fast jedem anderen Social Button funktionieren. Natürlich könnt ihr auch weiterhin die Ausgabe der Button im jeweiligen HTML-Code variieren; zum Beispiel beim Like Button von box_count auf button_count umstellen.

Das ganze kann man natürlich noch weiterspinnen und zum Beispiel an Hand der Bildschirmgröße festlegen, ob überhaupt alle oder bestimmte Buttons geladen werden sollen. Gerade auf Android Smartphones macht der Like Button eventuell weniger Sinn, wohingegen der +1 Button auf Grund des persistenten Google Logins durchaus in Betracht zu ziehen wäre.

Feedback, Kritik und Anregungen wie immer in die Kommentare. Ansonsten natürlich gerne teilen, damit unser Web in 2013 noch schneller und zugänglicher wird :)

Update: Buttons erst bei Mouseover laden

Der Viktor Dite hat mich in den Kommentaren zu diesem Artikel auf eine gute Idee gebracht. Man könnte die Social Buttons ja auch erst per Klick oder alternativ Mouseover austauschen. Die Idee finde ich so spannend, dass ich gleich mal das Script umgeschrieben habe. Natürlich sollte man statt einem Text bereits die entsprechenden Icons als Bild (CSS-Sprite) einbinden.

Wer statt Mouseover lieber per Klick laden lassen möchte, muss lediglich den Parameter „mouseover“ in Zeile 29 und 55 durch „click“ austauschen.

Was ist Responsive Webdesign überhaupt?

Vor wenigen Tagen habe ich einen sehr interessanten Satz auf Twitter gelesen, an dessen Autor ich mich leider nicht mehr erinnern kann. Die Aussage war aber ungefähr die folgende:

„Das Web war schon immer responsive, bevor wir angefangen haben, es in Container mit fester Breite zu verpacken.“

Diese Aussage trifft es natürlich auf den Punkt. Kein HTML-Element besitzt von Haus aus eine in Pixeln definierte Breite. Standardmäßig sind Inline-Elemente so breit wie ihr jeweiliger Inhalt; Block-Elemente hingegen besitzen immer eine Breite von 100%. Erst in dem wir Elementen über CSS eine feste Breite zuweisen, zerstören wir ihre Dynamik.

Natürlich konnten Webentwickler in der Vergangenheit nicht ohne das Definieren fester Breiten auskommen: Designs mussten „Pixel Perfect“ umgesetzt werden, ein 960 Pixel breiter „wrapper“ war Quasi-Standard.

Heute hat sich diese Situation geändert. Durch CSS-Eigenschaften wie „max-width“ oder Media Queries können wir Webseiten ausliefern, die zum einen wieder auf ein fluides Layout als Basis zurückgreifen und trotzdem auflösungsspezifische Eigenschaften besitzen. Auf dieser Grundlage ist es möglich geworden, Webseiten mit identischem HTML-Quellcode auf diversen Endgeräten vollkommen unterschiedlich darzustellen.

1. Tipp: Elemente verstecken

Der erste Tipp ist nicht einmal großartig technischer Natur. Vielmehr geht es darum, sich bewusst zu machen, dass Besucher von verschiedenen Geräteklassen auch durchaus andere Ansprüche an die zu besuchende Webseite stellen.

Ein gutes Beispiel dafür ist die klassische Restaurant-Webseite. Besucher, die die Seite mit einem Smartphone aufrufen, sind in der Regel nach konkreten Informationen: Öffnungszeiten, Wegbeschreibung, Speisekarte. Grafische Elemente und große Bilder sind hier eher unerwünscht.
Anders sieht es bei Besuchern aus, die über einen Desktop Browser kommen: Diese befinden sich nicht selten noch im Entscheidungsprozess. Es ist also auch wichtig, einen Eindruck über das Restaurant zu vermitteln, wofür sich der Einsatz von großen Slidern und Bildergalerien anbietet.

Als Webentwickler muss man sich und dem Kunden also bewusst machen, dass nicht alle Elemente, die eine Desktop-Variante beinhaltet, auch auf der mobilen Webseite Platz finden. Mut zum Kürzen lautet in diesem Fall die Devise.

Technisch lässt sich das ganze über die CSS3 Media Queries recht einfach umsetzen:

2. Tipp: Fluides Layout mit fester Breite

Die Basis für fast jedes responsive Webdesign sollte ein fluides Layout sein. Hier macht es aber durchaus Sinn, wieder auf feste Pixelgrößen zurückzugreifen um eine Maximalgröße zu definieren.

Fluides Layout auf einem 1920px Monitor: So macht Lesen nicht wirklich Spaß!

Stellen wir uns vor, wir besuchen eine fluide Webseite mit einem 27 Zoll iMac, der eine Auflösung von 2560 x 1440 Pixel besitzt. Würde sich der textuelle Inhalt nun über die gesamte Breite erstrecken, hätten wir ellenlange Wortreihen. Die Folge wäre, dass sich niemand mehr zwischen den Absätzen zurechtfinden beziehungsweise das Lesen extrem erschwert würde.

Um dies zu verhindern, macht es durchaus Sinn, dem Hauptcontainer („wrapper“) oder einzelnen Elementen eine maximale Breite mitzugeben. Technisch ist das ganze wieder schnell implementiert:

Der Schlüssel zum Erfolg ist in diesem Fall eine Kombination aus den CSS-Eigenschaften width und max-width. Dem Container geben wir eine Breite von 100%, wodurch er sich natürlich über das gesamte Browserfenster erstreckt. Über die Eigenschaft max-width definieren wir zusätzlich eine maximale Breite in Pixeln und margin: 0 auto sorgt dafür, dass der Container mittig zentriert wird, falls das Fenster breiter ist als der unter max-width angegebene Wert.

3. Tipp: Mehrspaltige Layouts untereinander anzeigen

Die meisten Webseiten-Layouts sind zwei- oder dreispaltig. Was bei Desktop-Auflösungen durchaus Sinn macht, ist bei kleineren Bildschirmen jedoch irgendwann störend. Stellen wir uns vor, wir haben einen Hauptinhaltsbereich mit 65% und eine Seitenleiste mit 35% Breite. Entspräche dies bei einer Fenstergröße von 1000 Pixeln noch angenehmen 650 zu 350 Pixeln, sähe die Situation bei einem Smartphone schon anders aus.

Eine Standardauflösung bei vielen Mittelklasse-Smartphones ist beispielsweise 480 x 800 Pixel. Dementsprechend wäre der Hauptinhaltsbereich ungefähr 310 Pixel und die Seitenleiste 170 Pixel breit. Hier würde es also definitiv mehr Sinn machen, beide Spalten auf 100% Breite zu bringen und untereinander anzuzeigen.

Mit Hilfe der CSS3 Media Queries stellt auch diese Implementierung kein Problem dar:

Responsive Webdesign: Nur ein Trend?

Ich hoffe ihr seht, dass man mit wenigen Kniffen und etwas Quellcode auch bereits bestehende Desktop-Webseiten um mobile Komponenten erweitern kann. Wer allerdings plant, einen Relaunch oder eine neues Projekt in Auftrag zu geben, sollte auf eine Agentur zurückgreifen, die responsive Webdesignes bereits anbietet; zum Beispiel ein HTML Webdesign von der Kreativagentur GSDH.

Denn die Zugriffe über mobile Endgeräte nehmen kontinuierlich zu, auf der anderen Seite wird die Gerätespanne und damit auch die unterstützten Auflösungen immer größer. Zwischen 360 und 2560 Pixeln ist heutzutage so ziemlich alles möglich. Fluide Layouts und Responsive Webdesign sind also keine kurzfristigen Trendthemen, sondern die Techniken der Zukunft und Gegenwart.