Boehrsi.de - Blog

Caching ist wichtig und erspart unnötiges Laden von Inhalten. Will man dies serverseitig tun wirft man, durch Einträge in die Apache Config oder .htaccess Datei, diverse Dateiformate in eine Liste und lässt diese für einen definierten Zeitraum cachen. Doch was ist wenn sich tatsächlich Inhalte ändern und man diese direkt ausliefern will. Vor allem an CSS oder andere statische Dateien denke ich dabei. Auch Bilder sind ein beliebtes Beispiel. Diese Inhalte sollen definitiv nicht jedes Mal frisch an den Nutzer gesendet werden, aber gerade bei Updates der Homepage oder neuen Inhalten möchte man selbige natürlich auch sofort sehen. Auch beim Entwickeln ist dies hilfreich, wobei man dort in diversen Browsern das Caching auch komplett deaktivieren kann. Lange Rede, kurzer Sinn, ich nutze nun einen sehr einfach Ansatz, wie er von Stefan Hayden open_in_new beschrieben wird und im unteren Teil der News von mir noch einmal erläutert wird.

Ich habe diverse meiner Homepage-Optimierungen schon mit euch geteilt und heute gibt es nicht wirklich was neues, sondern eher einen Hinweis auf bekanntes. Es geht darum auch die bereits durchgeführten Aktionen immer mal wieder zu überprüfen. Denn so habe ich z.B. gerade festgestellt, dass zum einen meine Volltextsuche im Blog wieder nur mit der Mindestlänge 4 für Worte funktionierte und das Caching auf Webserver-Seite deaktiviert war. Alle Konfigurationen waren aber seit den letzten Änderungen von mir unangetastet geblieben. Gründe für die Probleme waren Updates meines Servers und der dortigen Software. Obwohl ich alle Konfigurationen beibehalte, also meine geänderten und nicht die neuen Standard-Konfigurationen der aktualisierten Pakete nutze, gab es Probleme. Die Fehler habe ich behoben indem ich in einer separaten MySQL Konfigurationsdatei nun meine Einstellungen für die Volltextsuche auf die Mindestlänge 3 geändert habe (ft_min_word_len = 3) und indem ich via a2enmod expires das mod_expires Modul für Apache wieder aktiviert habe. Dies bringt mir einen PageSpeed Insights Score von 90 / 100 bei der Geschwindigkeit und 99 / 100 bei der Nutzererfahrung in der mobilen Ansicht. Bei der Desktop Version erreicht Boehrsi.de 96 / 100 Punkten. Die Abzüge bei der Geschwindigkeit sind minimal durch die weit oben eingebundene CSS Datei zu erklären, was ich in diesem Beitrag begründete. Der Großteil der Abzüge stammt aber von den extern eingebundenen Amazon-Anzeigen, auf welche ich natürlich nicht auf Code-Ebene zugreifen kann.

• Page Speed Webseite open_in_new

Während ich recht viel über konkrete Ansätze und Ideen schreibe, die mir halfen meinen Blog zu optimieren, gibt es ein paar Tools die eher allgemein helfen. Dadurch sind diese aber nicht minder wichtig. Eines von diesen erwähnte ich bereits in meinem ersten Beitrag zur Themenreihe. Dieses heißt Google PageSpeed und hilft euch einfach und schnell Flaschenhälse innerhalb der Ladezeiten eurer Homepage zu entdecken. Doch neben diesem gibt es auch noch die Google Webmaster-Tools, welche diverse Funktionen anbieten. Als erstes müsst ihr eure Seite dort einbinden und anschließend erhaltet ihr diverse Informationen und Funktionen. Für das Ganze wird ein Google Account benötigt, was aber für die meisten wohl kein Problem sein dürfte.

• Google Webmaster-Tools open_in_new

So langsam habe ich fast alle Themen bezüglich der Optimierung meines Web-Servers abgearbeitet und heute ist die Komprimierung von Inhalten das Thema. Dafür nutze ich, da Apache der Webserver meiner Wahl ist, das Apache Modul mod_deflate open_in_new. Selbiges habe ich relativ simpel konfiguriert, wobei ich mich wie schon zuvor erwähnt an die Einstellungen von html5boilerplate.com open_in_new halte. Denn diese waren bis jetzt extrem gut und brachten mir nur Vorteile. Diese haben sich im Vergleich zu meiner Konfiguration schon wieder etwas verändert aber dort werde ich größere Anpassungen erst wieder beim nächsten Umfangreichen Update durchführen oder aber wenn Fehler auftreten. Im unteren Teil findet ihr meine konkrete Vorgehensweise.

• HTML5 Boilerplate .htaccess Datei auf GitHub.com open_in_new

Einer der größten Datenproduzenten bei der Übertragung von Homepage-Daten sind Bilder. Selbige einfach wegzulassen sollte man allerdings nicht versuchen, denn was wäre eine Seite ohne Bilder. Aus diesem Grund muss man Bilder entsprechend optimieren. Das bedeutet zum einen die richtigen Formate zu verwenden und auf der anderen Seite die Bilder mit verschiedenen Tools so anzupassen, dass man hier und dort ein paar Bits und Bytes sparen kann. Denn insgesamt erreicht man dadurch tatsächlich eine spürbare Verkleinerung der Daten.

Wenn man weniger Daten laden muss geht alles schneller, klingt logisch oder? Dementsprechend soll man versuchen den Code, der an den Nutzer gesendet wird, zu minimieren. Es geht hierbei nicht darum was z.B. im PHP Backend passiert, sondern um die finalen Daten die transferiert werden müssen. Es ist dabei relevant HTML zu entschlacken aber auch JavaScript und CSS sollten nicht vergessen werden. In diesem Zuge habe ich durch die Umstellung auf einen komplett neuen HTML5 Code alles etwas “einfacher” gehabt. Denn dadurch achtete ich natürlich automatisch auf einen möglichst minimalen Unterbau. Ich verhinderte von Anfang an Inline CSS Nutzung und platzierte CSS direkt in Elementen ohne extra Klassen einbinden zu müssen. Außerdem legte ich möglichst viele ähnliche CSS Klasse zusammen und wendete sie auf diverse HTML Elemente an. Einzelne Unterschiede wurden dann extra abgearbeitet und insgesamt denke ich mit dieser Technik sehr gut gefahren zu sein. Vor der Auslieferung der CSS Datei an den Nutzer habe ich dann noch das Tool cssmin.js open_in_new über meine CSS Datei laufen lassen und konnte auch hier noch ein paar Bytes heraus holen. JavaScript versuche ich möglichst wenig zu nutzen, auch wenn die Möglichkeiten vielfältig sind. Dies ist damit begründet das man JavaScript blockieren kann und ich bin der Meinung eine Seite sollte grundsätzlich immer grundlegend funktionieren, auch ohne extra Skripte. In diesem Bereich erreichte ich die Minimierung also quasi einfach schon durch meine Vorstellungen von JavaScript Integrierung. Den wenigen Code den ich schrieb, erstellte ich in jQuery, was noch einmal etwas Masse spart. Aus diesem Grund nutzte ich kein weiteres Tool zur Code Minimierung, wie zum Beispiel JSMIN open_in_new. Alles in allem läuft meine Seite nun sehr schnell aber trotzdem möglichst Standard Konform, was häufig ein Problem ist.

• Tipps zur Code Minimierung (HTML, CSS und JavaScript) via developers.google.com open_in_new

Auch in der heutigen Zeit der Parallelität, ist es noch sehr wichtig an welchen Stellen man Code in seiner Homepage platziert. Dies gilt vor allem für externen Skripte und Style Dateien. Denn liegen Scripte an unpraktischen Stellen, kann es dazu kommen das sie den kompletten weiteren Ladevorgang der Seite blockieren und somit die eigentliche Darstellung merklich und unnötig verzögern. Es gibt verschiedene Vorschläge wie man am besten vorgehen kann und ich habe mich wie im unteren Teil der News beschrieben entschieden.

• Best Practices for Speeding Up Your Web Site via Developer.Yahoo.com open_in_new

Nachdem es im letzten Teil der Serie um die Minimierung von HTTP Requests ging, geht es heute mit Caching weiter. Denn um die Menge an Daten die geladen werden müssen zu reduzieren, ist es natürlich super sie einfach gar nichts an den Nutzer zu übertragen. Dies ist in manchen Fällen tatsächlich möglich, denn besucht ihr eine Seite häufiger, habt ihr einfach schon sehr viele der zu übertragenden Daten auf eurem PC. Dies betrifft z.B. die Bilder des eigentlichen Homepage Designs, Style Dateien und andere Inhalte die sich vielleicht nicht so häufig ändern. Doch was darf für welchen Zeitraum aus dem Cache geladen werden ohne das es vielleicht zu Problemen kommt? An dieser Frage scheiden sich die Geister und vor allem hängt dies auch sehr von der eigentlichen Homepage ab. Ein kleiner Hinweis noch, es geht nicht um das Caching innerhalb des Servers open_in_new, sondern um die Caching Funktionen vom Server die dem Nutzer einen unnötigen Datenaustausch ersparen.

• html5-boilerplate auf Github.com open_in_new

Wie im ersten Teil angekündigt werde ich nun, wenn auch mit einer doch recht langen Verzögerung, Stück für Stück über meine neue Seite berichten. Und da ich gerne von oben nach unten arbeiten möchte, beginne ich heute mit den HTTP Requests. Denn diese liegen meiner Meinung nach ganz oben. Bei meiner Reihenfolge kann es vorkommen das ihr anderer Meinung seid als ich aber ich denke das sollte verschmerzbar sein. Doch was sind eigentlich HTTP Requests? Kurz gesagt sind es die Anfragen die ihr an den Server stellt, sofern ihr Daten laden wollt. Ruft ihr also meine Seite auf, stellt ihr eine Anfrage an meinen Server euch die gewünschten Daten zu liefern. Eine Seite enthält eine Vielzahl von Elementen, wie z.B. Text, Bilder und Multimedia Inhalte. Die wollen geladen werden und das möglichst schnell und effektiv, wie ich dies auf meiner Seite versucht habe zu optimieren könnt ihr bei Interesse nun im unteren Teil der News lesen.

Heute beginne ich mit einer kleinen Reihe zur neuen Version meiner Homepage und dabei will ich mich von oben nach unten arbeiten. Ich beginne also an der Oberfläche und dem was man so direkt sieht und gehe dann immer weiter nach unten in den Code und das Backend. Heute ist das Thema die Geschwindigkeit meiner neuen Seite, denn die alte hatte diverse Fallstricke und Probleme. Diese waren mitunter so umfangreich das man tatsächlich spürbare Verlangsamung hatte und vor allem mit mobilen Geräten ist dies natürlich wirklich ein Problem. Um auf der neuen Seite solchen Problemen aus dem Weg zu gehen habe ich an diversen Schrauben gedreht und wenn man verschiedenen Analysetools glauben kann war ich erfolgreich. Dies könnt ihr im unteren Teil der News sehen, genau wie ein Überblick zu den kommenden Themen der Serie.