The Need for Speed: benedikt.io jetzt wesentlich schneller
23.1.2017· 3
In den letzten Jahren habe ich designtechnisch viel mit Constraints experimentiert: Wie viele Farben braucht eine Website wirklich? Wie einfach kann Navigation sein? Braucht man einen aufwändigen Header-Bereich?1 Während ich mit dem daraus entstandenen Design sehr zufrieden war, habe ich bis dahin auf eines nie wirklich geachtet: Geschwindigkeit. Allerdings sollte eine Webseite mit reduziertem Design auch schnell laden, oder? Genau das wollte ich ändern.
Nachdem ich die übliche »Ich schreib mein eigenes CMS«-Phase überwunden und Christophs superschnelle Website zum Benchmark erklärt hatte, machte ich mich ans Werk – und kam auf den Geschmack. Denn anstatt einfach nur ein Caching-Plugin zu installieren, begann ich darüber nachzudenken, wie man eine aufgerufene Seite mit nur einem einzigen, schnellen Request laden könnte – ohne dabei die Plattform zu wechseln (WordPress rockt).
Mit dem Ergebnis bin ich ziemlich zufrieden: Mit einer guten Verbindung ist das DOM von benedikt.io nun in 100 bis 150 ms geladen, vorher dauerte das mindestens rund 500 ms (meist sogar länger), von den zusätzlichen Requests für Webfonts etc. ganz abgesehen. Wahrscheinlich wäre mit einem Wechsel zu Amazon S3 bzw. CloudFront noch mehr drin gewesen, aber ich wollte wissen, was mit den mir zur Verfügung stehenden Mitteln alles möglich ist.
Redesign
Eine Folge dieser Bemühungen ist auch ein dezentes Redesign, da ich mit dem Verzicht auf die Requests für Webfonts auf Systemschriftarten zurückgreifen musste. Windows-User sehen also meinen Versuch, »Arial« so gut wie möglich aussehen zu lassen, während für Mac-User »Helvetica Neue« (bzw. »Helvetica«) zum Einsatz kommt. Man sieht, dass eine einzige Schriftart auch ausreichen kann (und wieder ein Constraint mehr).
Und wie?
Da es nicht ganz trivial ist, WordPress und seine Plugins dazu zu bringen, keine unnötigen Requests anzufordern und auch Caching so seine Tücken hat, werde ich meine Erfahrungen diesbezüglich als kleines, mehrteiliges Tutorial veröffentlichen – bleibt dran!
Update, März 2017: Siehe WordPress schneller machen, Teil 1: Caching.
- Die Antworten darauf sind übrigens eine, sehr und nein. ↩
Neueste Artikel
Schlagwörter
Bloggen · Performance · Redesign · WordPress
3 Kommentare
Kommentieren
Dieser Eintrag kann nicht mehr kommentiert werden.
sehr schön. und schnell 😉 ich hoffe dass die zeiten, dass auf jeder seite n webfonts eingebunden sind, bald wieder vorbei sind. immerhin gibt es ja auch gute system schriften. jetzt könntest du auf die zwei piwik requests auch noch verzichten, dann wäre dieser artikel mit nur einem request ausgeliefert worden 😀
Hi, Thomas, vielen Dank für dein positives Feedback! Gezielt eingesetzte Webfonts halte ich an und für sich für eine gute Sache, ich wollte nur bei dieser Designiteration bewusst darauf verzichten. Mit den Piwik-Requests hast du grundsätzlich Recht, allerdings brauche ich ein Analytics-Tool. Wie und ob man die Piwik-Requests optimieren kann bzw. ob es schnellere Alternativen gibt, muss ich mir noch anschauen – bin für Hinweise dankbar!
PS: Deine Seite ist ja extrem flott. Tipps? 😉
bzgl. piwik: du könntest piwik zB so einstellen, dass es die log files parsed und dir auswertet. oder du nutzt den guten alten webalizer.
bei meiner seite hab ich ehrlich gesagt noch gar nicht auf performance geschaut. wp-super-cache läuft in verbindung mit einem starken server.