unveil.js |
Blog zu den Themen Webentwicklung, technisches Online Marketing und Suchmaschinenoptimierung

PageSpeed: So machst du deine Website schneller

PageSpeed, ein Thema, welches auf jeden Fall polarisiert. Flattern durch meine Google+ Timeline immer mal wieder Beiträge von Entwicklern, denen es großen Spaß machen muss, Punkt für Punkt auf der Google PageSpeed Tools Skala nach oben zu klettern, so gibt es auch diejenigen, welche die Ladezeiten-Optimierung verachten oder sogar als unnötig abtun.

Das eine Optimierung auf geringere Ladezeiten und höhere Ladegeschwindigkeiten gar nicht so schwierig ist und in jedem Fall Sinn macht, möchte ich in diesem heutigen Blogartikel aufzeigen. Dafür habe ich meinen bislang längsten Screencast (45 Minuten) aufgenommen und eine kleine Präsentation erstellt. Dort findet ihr unter anderem 11 recht pragmatische Tricks, um den PageSpeed Score euer Webseiten zu verbessern. Weiter unten im Artikel findet ihr dann auch noch die in der Präsentation erläuterten Maßnahmen zum direkten Copy&Paste :)

11 Tipps für performantere Webseiten

Vorweg natürlich noch die Bitte: Falls etwas unklar ist, ihr Rückfragen habt oder ich im Video etwas falsch erläutert haben sollte, nutzt einfach die Kommentarfunktion unter diesem Blogartikel.

Natürlich möchte ich euch auch die Slides aus der Präsentation nicht vorenthalten:

Vorteile von schnelleren Webseiten

Besseres Nutzererlebnis

Ich finde es immer spannend, mein eigenes Surfverhalten objektiv zu betrachten und dahingehend Rückschlüsse zu ziehen. In einigen Punkten ist dies als Webentwickler wahrscheinlich schwierig bis gar unmöglich; aber ich glaube, wenn mir etwas sauer aufstößt oder ich irgendwo hängen bleibe, dann geht es dem Otto-Normal-Surfer ähnlich. So verhält es sich auch beim Thema PageSpeed: Niemand surft gerne auf langsamen Webseiten!

Schnell geladene Seiten können also durchaus in einem hohen Maße zu einer besseren Nutzererfahrung beitragen. Teilweise spielt die Geschwindigkeit eine ähnlich große Rolle wie das eigentliche Layout der Webseite. Es ist erwiesen, dass eine Verbesserung der Ladezeit zu geringeren Absprungraten führt.

Verstärkt wird dieser Effekt beim Surfen mit mobilen Geräten, wo vor allem in ländlichen Regionen nur schlechte Datenverbindungen (Edge, GPRS, …) verfügbar sind. Dort ist es besonders wichtig, den mobilen Besuchern optimierte Webseiten bereitzustellen, da ein Absprung ansonsten fast vorprogrammiert ist.

Google Ranking-Faktor

Anfang 2012 gab Google bekannt, dass die Ladezeit von Webseiten ab sofort ein offizieller Ranking-Faktor ist. Der PageSpeed kann dementsprechend also dazu beitragen, an welcher Position in den Google SERPs eine Seite auftaucht. Zwar betrifft dies wohl nur ca. einen Prozent der Suchanfragen; aber beim Panda und Penguin-Update war die Zahl ja bekanntlich auch nicht viel höher und die Aufschreie aus der SEO-Szene trotzdem groß. Es kann also durchaus sein, dass PageSpeed in hart umkämpften Märkten ziemlich wichtig geworden ist.

Das die Ladezeit für Google eine Herzensangelegenheit ist, wird an vielen Stellen klar. Da wäre beispielsweise das von Google entwickelte PageSpeed Tool, mit dem sich sich komfortabel eine Geschwindigkeits-Analyse jeglicher URLs durchführen lässt.

Nicht wenige sind auch der Meinung, Google wolle keine schnelleren Seiten für die Besucher, sondern für die eigenen Crawler. Denn ob eine Website nach 0,5 oder erst nach 3 Sekunden gecrawled ist, stellt bei mehreren Milliarden Seiten natürlich auch einen großen wirtschaftlichen Faktor dar.

Wirtschaftlichkeit

Schnelle Webseiten tuen also Google und dem Besucher etwas Gutes. Nein – halt – auch das eigene Portmonnaie profitiert davon!

Eine von Amazon in Auftrag gegebene Studie besagt beispielsweise folgendes:

Often quoted research on this subject includes an Amazon study that showed a 1% decrease in sales for every 0.1s decrease in response times.
(Kohavi and Longbotham 2007)

Diese Zahlen muss man sich erst einmal auf der Zunge zergehen lassen: Lädt der eigene Online-Shop eine einzige Sekunde länger, könnte man ca. 10% seines Umsatzes verlieren – Wahnsinn!

So machst du deine Website schneller

An dieser Stelle möchte ich die im Video gezeigten Maßnahmen noch kurz erläutern und entsprechende Quellcode-Bausteine zum Copy&Paste bereitstellen.

1. http-Request reduzieren

Die Reduzierung von http-Request ist eines der wichtigsten Werkzeuge bei der Performance-Optimierung von Webseiten. Da das Hypertext Transfer Protocol (HTTP) keine dauerhafte Verbindung ermöglicht, muss der Server für jede Datei (Bild, Javascript, CSS, …) immer wieder erneut angefunkt werden. Dabei werden natürlich auch nicht benötigte http-header wie Cookie übertragen.

Der erste Schritt bei der Reduzierung von http-Request ist es, herauszufinden, welche Dateien überhaupt geladen werden. Im Google Chrome beispielsweise machst du dazu einen Rechtsklick auf eine freie Stelle und klickst auf “Element untersuchen”. Anschließend wählst du im obigen Reiter “Network” aus und aktualisiert danach die Webseite.

Interessant: HTTP-Request auf google.de – viele Inhalte werden per XHR nachgeladen

2. Javascript und CSS auslagern

Durch das Auslagern von Javascript- und CSS-Dateien macht man diese cachebar. So müssen sie beim nächsten Seitenaufruf nicht erneut geladen werden.


wird zu

Anmerkung: Auf sogenannten Single Landing Pages bietet es sich wiederum an, sämtliches CSS und Scripts im HTML zu platzieren, um sich zusätzliche http-Request zu sparen.

3. Javascript und CSS komprimieren

Komprimierte CSS- und Javascript-Dateien sind von der Dateigröße her meist wesentlich kompakter, da Kommentare oder nicht benötige Leerzeichen entfernt werden.


wird zu

Es gibt übrigens sehr viele praktische Online-Tools zum Komprimieren von Javascript- oder CSS-Dateien.

4. Javascript erst nach DOM parsen

Wird viel Javascript vor dem eigentlichen Inhalt der Webseite (<body></body>) geladen, kann dies den Seitenaufbau verzögern, da der Browser erst auf die fertig geladenen Javascript-Dateien warten muss.


wird zu

 5. Browser-Caching nutzen

Der Server kann dem Browser übermitteln, wann eine Datei das letzte Mal verändert wurde oder wann sie wieder aus dem Cache entfernt werden soll.

Caching per .htaccess aktivieren

Mehr Informationen zu mod_expires. 

Caching per PHP

Google empfiehlt übrigens, Bilder mindestens eine Woche im Cache zu belassen.

6. CSS Sprites nutzen

Die Idee hinter CSS Sprites ist es, mehrere Bilder oder Icons zu einer einzigen Grafik zu kombinieren, um http-Request zu sparen. Zum Thema Sprites habe ich bereits einen gesonderten Artikel geschrieben, in dem man sich weiter informieren kann.

7. Skalierte Bilder bereitstellen

Bilder sollten immer in dem Format auf dem Server liegen, in dem sie später auch wirklich ausgegeben werden. Es ist fatal, ein 800×600 Pixel großes Bild über den Browser als 200 Pixel Thumbnail auszugeben, da trotz Breitenangabe das Orginalbild (welches ja wesentlich größer ist) vom Server angefordert werden muss.

Außerdem sollte man beachten, wenn möglich immer die Attribute width und height anzugeben. Ansonsten kann der Browser den Platz für das Bild noch nicht reservieren und muss nach dem Laden des Bildes die Seite neu rendern.

8. Bilder optimieren

Abspeichern ist nicht gleich abspeichern – Bilddaten sollten immer für die Verwendung im Web optimiert werden. Dazu zählt beispielsweise die Wahl des korrekten Formates; im Vorfeld kann man fast nie sagen, ob JPG oder PNG besser komprimiert.

Wenn man mit Photoshop arbeitet, sollte man immer den Weg über “Datei” => “Für Web und Geräte speichern” gehen, um Bilder ohne unnötige Meta-Informationen abzuspeichern. Dort kann man dann auch direkt Testen, welches Format die kleinere Datei erzeugt.

Zudem gibt es Online-Tools wie jpegmini.com oder tinypng.org, die bereits vorhandene Bilder fast verlustfrei komprimieren können.

9. Ressourcen von Subdomain laden

Um das Browser-Limit von (meistens) 2 bis 4 aktiven Verbindungen gleichzeitig zu umgehen und um bei statischen Ressourcen nicht benötige HTTP-Header (wie z.B. Cookie) nicht extra mitsenden zu müssen, kann man auf Subdomains zugreifen.


wird zu

Google bietet zu diesem Thema einen eigenen Artikel Serve static content from a cookieless domain.

10. Dateien komprimieren

Dateien lassen sich per GZIP oder Apache deflate-Modul komprimieren, um die Dateiübertragung zwischen Browser und Server zu verkleinern.

Innerhalb von PHP-Dateien lässt sich zur GZIP-Komprimierung die Funktion ob_start() im Zusammenspiel mit der Callback-Funktion ob_gzhandler() nutzen:

Das deflate-Modul lässt sich hingegen per .htaccess global für verschiedene Datei-Typen definieren:

Vor allem sehr große CSS- und Javascript-Dateien mit vielen sich wiederholenden Elementen können dadurch deutlich kleiner werden.

11. Hoster wechseln

Gerade bei reinen Webspace-Paketen tummeln sich meist 50 Domains oder mehr auf dem gleichen Server. Häufig entstehen also bereits hier Flaschenhälse, die sich durch einen eigenen Server oder vServer vermeiden lassen. Wer überprüfen möchte, mit wie vielen anderen Domains man sich einen Webspace teilt, kann auf Online-Tools wie beispielsweise my-ip-neighbors.com zurückgreifen.

Aber auch zwischen den einzelnen Anbietern gibt es durchaus große Unterschiede; und das nicht nur in Sachen Support, sondern auch bei der Geschwindigkeit. Gerade im Hinblick auf Amazon Conversion-Studie sollte man sich überlegen, ob man bei einem Billig-Provider nicht am falschen Ende spart.

Ich persönlich bin übrigens mit allen Webseiten vor einiger Zeit zu ALL-INKL.COM umgezogen und fühle mich dort pudelwohl :-)

Fazit: Eine PageSpeed-Optimierung lohnt sich immer!

Es gibt keine Ausreden: Jeder sollte seine Webseite auf eine geringere Ladezeit und höhere Ladegeschwindigkeit optimieren. Damit tut ihr euren Besuchern, Google und im Falle eines Online-Shops auch euer Konversions-Rate etwas Gutes.

Das schöne an der Sache ist ja, dass sich ca. 80% der wichtigsten Maßnahmen in relativ kurzer Zeit und mit wenig Aufwand umsetzen lassen.

Also, worauf wartet ihr? Jeder liebt schnelle Webseiten! :)

 

Bildquelle Thumbnail: https://developers.google.com/speed/pagespeed/

Dieser Artikel wurde am 03.07.2012 veröffentlicht

Wer schreibt hier?

Torben Leuschner - Webentwickler

Hi, ich bin Torben und baue leidenschaftlich gerne Webseiten. Also habe ich mein Hobby zum Beruf gemacht und bin seit 2008 als Webentwickler Selbständig tätig. Obwohl ich schwerpunktmäßig für Kunden arbeite habe ich auch sehr viel Freude an der Realisierung eigener Projekte. Daraus resultierend hat sich eine große Affinität zu den Themen Online Marketing und Suchmaschinenoptimierung entwickelt. Regelmäßig schreibe ich auf Twitter, noch aktiver bin ich allerdings auf Google+.

Wie stehst du dazu?

  1. Hallo Torben,
    der Beitrag ist wirklich gut gelungen. Es gab zwar schon dutzende Beiträge in diversen Blogs, die bereits alle Themen beschrieben haben, aber du bringst es alles zusammen auf einen Punkt.
    Ein Modul kann man hier noch nennen, was wirklich sinnvoll ist SPDY-Protokoll.
    Gruß
    Marco

    • Hallo Marco,

      vielen Dank für dein positives Feedback! :)

      Das SPDY-Protokoll ist natürlich ebenfalls eine sehr relevante Maßnahme und zeigt ebenfalls, wie wichtig Google das Thema PageSpeed ist.

      Eventuell bekommt SPDY nochmal einen eigenen Artikel, denn von den hier genannten Maßnahmen würde ich es auf Grund seiner Kompatibilität nochmals abgrenzen.

      Viele Grüße,
      Torben

  2. Insgesamt eine gute Übersicht, allerdings habe ich zu Punkt 11 ein paar Anmerkungen.

    Die Anzahl der Domains auf einer IP-Adresse sagt nicht unbedingt viel über die tatsächliche Verteilung und Auslastung der Server aus. Das kann hinter der IP-Adresse auch geschickt auf Server verteilt werden. 10000 Domains auf einer IP-Adresse bei Strato können durchaus deutlich performanter sein, als 100 bei einem “kleinen Krauter”.

    vServer stellen nicht unbedingt einen Performance-Gewinn dar. Ein vServer teilt sich auch die Hardware-Ressourcen mit anderen vServern. Nachteil beim vServer ist, daß er nicht nur die Ressourcen für das Webhosting bereitstellen muß, sondern auch für das Betriebssystem.
    Eigentlich ist das Ressourcenverschwendung. Auf der selben Hardware ist ein gut konfiguriertes Shared-Webhosting effektiver als viele vServer.

    • Hallo,

      vielen Dank für deine Anmerkung. Habe die Sache mit dem vServer aus dem Artikel gestrichen.

      Ich wollte damit nur aussagen, dass man bei den Hosting-Kosten auch am falschen Ende sparen kann :)

      Viele Grüße,
      Torben

  3. Eine gute Zusammenfassung der wichtigsten Möglichkeiten. Zu einem Punk habe ich allerdings eine kleine Anmerkung.

    > 9. Ressourcen von Subdomain laden

    Inzwischen unterstützen alle gängigen Browser in der Standardkonfiguration bereits sechs Verbindungen pro (Sub-)domain. Zusätzlich muss man beachten, dass eine weiterer Hostname auch immer einen weiteren DNS-Request mit sich führt, wodurch der vermeintliche Performancegewinn schnell wieder dahin ist.

    Anders sieht dies für mobile Webseite aus. Hier sind parallele Request durch unterschiedliche Domains durchaus sinnvoll.

    Google für seinen Teil rät inzwischen von dem Einsatz von (Sub-)domains ab.

    VG Marcel

  4. Gute Zusammenfassung für ein schnelles Performance-Lifting ohne großen Aufwand. Ich würde noch hinzufügen: “Keine Like-Buttons beim Seitenaufbau laden”. Wie die Teile eine Seite teilweise ausbremsen, ist echt nicht mehr feierlich.

  5. Hallo Torben,
    ich habe mich auch schon sehr lange mit dem Thema beschäftigt. Zwei Fragen dazu:
    1. Den JavaScript Code in den Body stecke… Bei mir habe ich beobachtet, dass dann einige Scripte nicht mehr richtig laufen. Gibt es hier Ausnahmen, die unbedingt im Head Bereich stehen sollten?
    2. Thema Ressourcen auf Subdomain auslagern. Finde die Idee auch Klasse aber hatte damit in der Praxis so meine Probleme wenn SSL zum Einsatz kommt. Dann meckert der Internet Explorer rum, dass Ressourcen von einer unsicheren Seite geladen werden sollen. Der Browser hat ja auch recht weil die Subdomain kein SSL Zertifikat besitzt. Gibt es dafür eine Lösung außer der, dass man der Subdomain auch ein Zertifikat spendiert??

    Viele Grüße,
    Martin

    • Guten Morgen Martin,

      zu 1.)
      Generell sollte es keinen Unterschied bei der Ausführung machen, sofern viele Frameworks (z.B. jQuery) ja sowieso eine document.ready() Funktion bieten, die wartet, bis der DOM vollständig geladen wurde.

      Eventuell kann es vorkommen, dass über Javascript gesteuerte Elemente wie Slider anfangs unschön dargestellt oder falsch geladen werden – solange, bis dann das Javascript zur Verfügung steht. Hier kann man aber meist mit etwas CSS gegenarbeiten.

      Wichtig: Die Reihenfolge der Scripte ist teilweise durchaus relevant und sollte eingehalten werden!

      zu 2.)
      Wie gesagt kupfer ich immer gerne bei den ganz großen ab, denn die sollten ja eigentlich wissen wie es geht.
      Google beispielsweise verwendet die zweite von Dir angesprochene Variante, welche ich ebenfalls präferieren würde. Beispielsweise findest du auf der Google-Startseite ein Sprite, welches von einer https-Static-Domain geladen wird:
      https://ssl.gstatic.com/gb/images/j_e6a6aca6.png

      Eine Fehlermeldung die in irgendeiner Weise die Sicherheit der aktuellen Website für den Besucher in Frage stellt, würde ich um jeden Preis vermeiden wollen!

      Viele Grüße,
      Torben

  6. Hallo Torben,

    ein absolut gelungener Beitrag zum Thema Page Speed. Viele drängen das Thema in den Hintergrund. Aber ich finde es sehr wichtig. Den ein oder anderen Tipp werde ich umsetzen! Besonders den CSS Sprites Tipp werde ich mir genau ansehen.

    Danke dafür!

  7. Sehr guter, informativer Beitrag, dankeschön.

    Viele wertvolle Tipps dabei, die ich ganz sicher bei meinem aktuellen Design re-launch mit einfließen lassen werde!

  8. Interessantes Tutorial, viele nützliche Anmerkungen, die mir den nötigen Anstoß gegeben haben, mich auch mit der Optimierung meiner Seite zu befassen (befindet sich noch in der Produktion).
    Hört man aber Deinen Screencast, merkt man schnell, dass Englisch alles andere als Deine Stärke ist und das schlägt sich leider unter Anderem auch in Deinem htaccess-Code nieder. Es heißt z.B. ,hours’ und nicht ,houres’ und ,kitten,’ nicht ,kidden.’
    Abgesehen davon bekommt Dein Blog selbst nicht die allerdesten Werte von Google PageSpeed. Deshalb wäre es vielleicht ratsam gewesen, die „80% der wichtigsten Maßnahmen“ vor dem Tutorial erst einmal selbst anzuwenden, da sich sich ja laut Deiner Aussage „in relativ kurzer Zeit und mit wenig Aufwand umsetzen lassen.“ Abgesehen davon, vielen Dank für den Anstoß.

    • Hallo Daniel,

      vielen Dank für dein Feedback! :)

      Die Screencasts nehme ich meist direkt am Stück und ohne großartige Vorbereitung auf. Den ein oder anderen Sprachpatzer bitte ich deshalb zu verzeihen und gelobe Verbesserung.
      Die beiden von dir angesprochenen konkreten Rechtschreibfehler habe ich natürlich sofort korrigiert.

      Deiner letzten Aussage kann ich allerdings nicht zustimmen. Die Startseite meines Blogs erhält folgende Bewertung:
      Die Seite Torben Leuschner – Blog über Webentwi… hat einen Gesamt-PageSpeed Score von 92 (von 100 Punkten) erhalten.
      Diesen Wert finde ich für einen Blog mit dynamischen Inhalten (keine Landingpage) akzeptabel. Siehst du das anders?

      Viele Grüße,
      Torben

      • Ich habe Deine http://www.torbenleuschner.de/ auf gtmetrix.com getestet (ich kann das Tool nur empfehlen), dort bekam die Seite nur 89 Punkte (Page Speed) und 81 (Yslow). Allerdings steht der Testserver in Dallas. Gerade habe ich noch einmal mit Google Page Speed gestestet, wo die 92 Punkte gegeben wurden, die Du erwähntest. Es handelt sich also um ein Missverständnis.

        http://gtmetrix.com/reports/www.torbenleuschner.de/fnR7taSy

        Um Deine eigentlich Frage zu beantworten, alles über 90 Punkten im Desktop-Bereich finde ich ausreichend, ab 95 kann man sich bei komplexeren Seiten sicherlich rühmen. Allerdings habe ich in den letzten Tagen während meiner Recherche gelernt, dass zu einem Gefühl des ,schnellen Surfens’ mehr gehört, als die rein physikalische Lade- und AUsführgeschwindigkeit. Zu langsame Animaionen, behindernde Elemente in der UI, unnötige Widgets und dergleichen machen die Erfahrung gerade bei eigentlich schnellen Seiten schnell unfreiwillig zunichte.

        Meine Seite ist ein WordPress-Blog, also auch keine Landing Page. Dort erziele ich (noch immer testend) zwar 97 Punkte, muss aber auch zugeben, dass sich der Gesamtinhalt noch in Grenzen hält. DIe richtige Verteilung und Gewichtung von Inhalten trägt aber sicherlich auch dazu bei, inwieweit sich das Gefühl einstellt, eine schnelle Webseite zu betrachten.

        Gemessen an der Menge des Inhalts ist Dir mit 92 Punkten also sicherlich schon eine Optimierung gelungen, die viele täglich zu hunderttausenden aufgerufenen Webpräsenzen noch immer vermissen lassen.

        Das Thema Mobile-Surfing ist wieder ein anderes. Das lässt sich wiederum erst beurteilen, wenn eine Webseite auch für Mobile Devices ausgelegt ist.

  9. Ich bin gerade auch dabei, meine Internetseite zu optimieren und da habe ich diese auch testen lassen.
    Dabei wurde mir unter anderem folgendes angezeigt:
    Header des Typs “Vary: Accept-Encoding” angeben
    was bedeutet das und was muss ich tun um das Problem zu beheben?
    Vorab schon mal vielen Dank

    • Hallo Isabell,

      hast Du dir Punkt 10. “Dateien komprimieren” angeschaut?
      Mittels einer GZIP oder mod_deflate Komprimierung müsstest Du das “Problem” in den Griff bekommen :)

      Viele Grüße,
      Torben

  10. Ach so ist das. Danke für deine Antwort!
    Leider ist dieses Modul für die GZIP-Komprimierung nicht vorhanden. Wahrscheinlich werde ich den Anbieter wechseln.
    Nochmals Danke für deine Antwort.

  11. Hallo Torben,

    danke für den informativen Artikel! Er hat mir noch ein paar weitere Anregungen für Optimierung gegeben, die ich nun umsetzten werde!

    Gruß
    Daniel

  12. Hallo Torben,

    Du lieferst hier einen sehr guten Überblick über Möglichkeiten zur Optimierung des PageSpeed.

    Einen weiteren Punkt habe ich aber noch:

    12. CSS-3 statt Grafiken
    Mit CSS-3 kann man wahnsinnig viel an Speed gewinnen, weil man mit ein paar Zeilen Code einen Haufen an Grafiken ersetzen kann. Z.B. kann man einem Div abgerundete Ecken, einen Farbverlauf, einen Schein nach innen und einen Schlagschatten verleihen. und und und…

    Beste Grüße
    Ansgar

  13. Hallo Torben,

    ich finde deinen Beitrag klasse. Allerdings warte ich gespannt auf den “spannenden Extra-Beitrag über Social Buttons”. Das würde mich echt mal interessieren, wie du damit umgehst, da ich bis jetzt immer das Problem hatte, dass Social Buttons die Ladezeit erheblich bremsen.

    Gruß,
    Jens

  14. Wieder mal ein paar geniale Tipps. Die Ladezeit ist schon sehr wichtig, deshalb habe ich vor einiger Zeit meine Seiten zu optimieren. Doch das ist nicht immer wirklich leicht, gerade dann nicht, wenn man technisch nicht so versiert ist. Am besten finden ich den Tipp mit der Auslagerung auf eine Subdomain. Das werde ich jetzt als nächste bei allen Projekten erstmal tun.

  15. Hallo,
    ich habe gerade deine Code für das Browser Caching anstatt meines nicht funktionierenden Codes getauscht. Jetzt bin ich von 93 auf 61 zurück gefallen.
    Wo muß ich den Code genau einfügen – es gibt ja mehrere Stellen.

    hast du sonst noch eine Idee für eine bessere Performace bei meiner Seite http://www.alexanderriegler.at.

    Ich setzte auf Zugriffe nicht Ladezeit. Für mehr Zugriffe, brauche ich vermutlich aber eine bessere Ladezeit …

    Danke,
    Alex

  16. Hi Alex,

    so wie ich das sehe, funktioniert laut Page Speed Tool deine Browsercaching-Implementierung korrekt.

    Lediglich externe Ressourcen, auf die du keinen Einfluss hast, haben keine festgelegte Cache-Ablaufzeit.

    Ansonsten kannst du noch versuche, die HTTP-Requests zu minimieren. Vor allem CSS- und JS-Dateien lassen sich bei Dir noch gut zusammenführen.

    Gruß,
    Torben

  17. Vielen Dank für die rasche Antwort und den Tipp mit dem Zusammenführen von Datein. Meiner Meinung nach sollte diese Arbeit bereits vom jch-optimize plugin (Combine JavaScript Files: yes und Combine CSS Files: yes) erledigen. Das JS CSS Control Plugin habe ich nun deaktiviert – es macht ja scheinbar das gleiche.
    Meine hTTP requests werde ich mir mit http://www.webpagetest.org gleich mal ansehen. Danke für die Tipps.

  18. Hallo Torben. Ich lese oft bei deinen Beiträgen mit und finde sehr vieles interessant. Auch das angesprochende Thema PageSpeed beschäftigt mich schon seit Langem. Inzwischen bin ich bei einem PageScore von 99 angelangt und habe auch fast alles umgesetzt, was Google vorschreibt.

    Jetzt wollte ich den 100er knacken, allerdings scheitere ich an der LOSSLESS Compression von Bildern und an einer Kleinigkeit bei der HTML Verkleinerung.

    Google schreibt mir da “Durch die verlustfreie Komprimierung von…könnten Sie 878 B einsparen (Reduzierung um 5%)”.

    Ich verwende für die Bilder ein Script, welches die Daten serverseitig aufbereitet. Scheinbar ist JPG hier das Problem (vermutlich wegen irgendwelchen Comment Tags) – kann das sein ? Aus Browserkompatibilitätsgründen (Seite soll ab IE 5 immer gleich aussehen) verwende ich nämlich ungern PNG).

    Was HTML betrifft bin ich auch noch am Rätseln, was Google da alles reduzieren will. Würde ich die Seite entsprechend deren Vorschlägen ändern, ist sie zwar superklein und komprimiert, sieht aber entsprechend besch** aus.

    Ein weiteres Thema wurde auch noch nicht angesprochen, und zwar dieses hier: http://blog.nihilogic.dk/2008/05/compression-using-canvas-and-png.html

    Klingt für mich interessant und ist vielleicht eine Alternative für “große” JS Projekte…

    • Ich antworte mir mal selbst :-)

      Inzwischen ist es mir gelungen, auch Bilder für Google Pagespeed on the fly verlustfrei zu komprimieren und dabei auch noch die ganzen überflüssigen GD Comments loszuwerden. Jetzt brauche ich nur noch einen Tip für HTML. Gibt es eine Möglichkeit, valide zu sein und trotzdem notwendige “Cond. Comments” durch weniger Bytes zu ersetzen ? Derzeit bin ich bei aber schöner wäre es, wenn ich ganz darauf verzichten könnte ?! Es geht mir hier insbesondere um das CSS Menü, welches uA. folgenden Aufbau hat:


      ...

  19. Sehr guter und ausführlicher Artikel.
    Ich würde auch einigen zum Beispiel den (kostenlosen) Dienst von Cloudflare sehr ans Herz legen.

    Habe da auch noch ein paar Tipps: http://pdf.daniel-ruf.de/
    Vielleicht sind diese auch hilfreich.

    Mit den dort erwähnten Lösungen bekommt man die besten Resultate =)

  20. Moin Torben!

    Super Leitfaden und sehr verständlich dein Artikel. Ich konnte dank deiner Anleitung bei der PageSpeed Analyse Werte zwischen 80 und 90 erzielen.

    Zur Zeit wird mir in der Kategorie “Hohe Priorität” die Aktivierung von “Keep-alive” angezeigt. Mein Provider (domainFACTORY) warnt davor. Hast du Erfahrungen mit dem Keep-alive Modul?

    • Hi Anton,

      schön, dass Dir der Artikel gefällt! :)

      Bezüglich Keep-alive findest du hier einige Hinweise:
      http://httpd.apache.org/docs/2.0/mod/core.html#keepalive

      Teilweise habe ich auch schon gelesen, dass eine Verwendung auf Seiten mit sehr hohem Besuchervolumen die Ladezeit negativ beeinflusst. Das es sicherheitstechnisch bedenklich ist, ist mir nicht bekannt (was aber nichts heißt).

      Generell liegt die Entscheidung über die Verwendung dieses Moduls meines Wissens sowieso größtenteils beim Hoster, weshalb du da wohl wenig machen kannst. Ich würde eventuell nochmal direkt bei domainFACTORY nachhaken, wo denn die konkreten Nachteil von Keep-alive liegen sollen.

      Gruß, Torben

      • domainFACTORY:

        “Hiermit möchten wir Ihnen mitteilen, dass es in Ihrem Tarif nicht
        möglich ist KeepAlive zu aktivieren, da eine Änderung an der
        Konfiguration Auswirkungen auf alle Kunden hätte, die sich auf dem
        Server befinden und wir so die Systemstabilität nicht mehr
        gewährleisten könnten. Gerne können Sie uns daher einmal mitteilen wo
        Sie dies im Forum gelesen haben, so dass wir dies entsprechend prüfen
        können.

        Generell raten wir auch von der Aktivierung ab, da es hierbei zu
        Komplikationen und möglicherweise zu Beeinträchtigungen in der
        Erreichbarkeit der Webseiten kommen kann.”

        Ok. Läuft also nur beim Tarif ManagedServer. Bei ManagedHosting liegen mehrere Kunden auf einem Server.

  21. Danke für die vielen Infos! Habe versucht einige davon umzusetzen, aber ich gleube mein größtes Problem ist mein Hoster…
    Da muss ich wohl mal mit denen sprecen!

    Viele Grüße
    Heike

  22. Nur auf die Website laden, was drauf muss. Platzsparende Dateiendungen verwenden. Alles runter, was Platz raubt. Die Website muss schnell werden.

  23. Hallo Heike,

    das bezog sich hauptsächlich auf die Bilddateien. Da wird bei .gif, .jpg, .bmp usw. unterschiedliches Speichervolumen benötigt. Bei Texten vielleicht .pdf, aber da gibts bestimmt auch noch bessere Möglichkeiten.

  24. Super Artikel, besten Dank fürs zusammenfassen.
    Da ich mich auch seit einiger Zeit mit dem Thema befasse, hier noch eine kleine Frage. Was hälst du von der Nutzung von CDNs (Content Delivery Networks)?
    Häufig habe ich gelesen, dass der Weg über ein CDN teilweise eine signifikante Steigerung der Geschwindigkeit mit sich bringt. Hast du damit bereits Erfahrungen? Ich bin kurz davor das Angebot von Cloudflare auszuprobieren.

    Und soeben fällt mir noch eine zweite Frage ein: Pagespeed und Yslow meckern auf meinen responsive Sites eigentlich immer bzgl “Skalierte Bilder bereistellen”. Ich sehen, dass deine Seite ebenfalls responsive ist und dieser Hinweis nicht gegeben wird. Was ist dein Trick?

    Viele Grüße
    Mirco

  25. Hallo Torben,

    danke für die kurze Anleitung/den Ansatz. Seit einigen Kommentaren hat sich dein PageSpeed hat einiges verbessert.

    Hatte gerade deinen Blog mal getestet und ich dachte ….wtf….. 97/100!

    Und ich war froh, das ich auf 90/100 komme, jetzt nicht mehr.

    Verrätst du vielleicht, was du genau von all-inkl-Hosting nutzt für deine Webseiten. Weil irgendwie bin ich mit meinem Hosting nicht ganz zufrieden, die Server-Response-Time ist immer zwischen 0.5 – 0.9 Sekunden.

    Nachdem ich dein Ergebnis gesehen habe, hat es mich doch angespornt an meinem zu arbeiten.

  26. Hi Tim,

    vielen Dank für das Lob, aber so schwierig ist das bei einem recht minimalistischen selbstgeschriebenden Theme eigentlichen gar nicht ;-)

    Bei All Inkl liegt dieser Blog zur Zeit auf einem einfachen Webhosting-Paket. Ich meine es wäre “Business”. Also nichts besonders.

    Die Response Times könnten sicher etwas besser sein, allerdings finde ich sie im Preis/Leistungs-Verhältnis in Ordnung. Wer noch mehr benötigt, muss dann eben auf einen Root-Server umsatteln :)

    Gruß, Torben

  27. Hallo Torben,

    normalerweise überfliege ich Blogartikel nur, aber Dein Artikel war sehr ausführlich und vor allem verständlich geschrieben und hat mich regelrecht gefesselt. Passend dazu noch das Video mit Deinen Erklärungen, von denen ich schon einiges kannte, aber auch einiges Neues erfahren habe, an dem ich in Zukunft noch arbeiten werde bzw. muss.

    Interessant fand ich den Tipp von Marco über das SPDY-Protokoll. Das habe ich auf meinem Server vor ein paar Tagen erst installiert und festgestellt, das sich dei Ladezeit tatsächlich reduziert.

    Danke für diesen ausführlichen Beitrag

    Schönen Sonntag noch

    Salu2 El

Hinterlasse eine Antwort

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *

Du kannst folgende HTML-Tags benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

eMail-Benachrichtigung bei weiteren Kommentaren.
Auch möglich: Abo ohne Kommentar.