Danny Fischer

Designer × Developer

The Critical Rendering Path: You’ve probably heard about it if you’re living in the front-end world. Against the do not mix HTML and CSS philosophy, it’s highly effective to put the render-critical parts of your stylesheet directly into the delivered HTML response. 1

But this article is not a pro and cons list of this technique — which will be deprecated if HTTP/2 is ready, rather a solution for one fundamental problem of the available tools: They are supposed to be used with static, highly predictable sites where deliverable HTML (generated by Jekyll or Middleman for example) files lying around, waiting to be analyzed.

Usually we build applications which are not static, but dynamic at a larger scale with varying layouts and templates, though. To extract the render critical CSS in those cases, we need to send actual HTTP Requests to evaluate what is critical on the pages in question.

Render Critical CSS Workflow / Overview

The Solution

We need three things in order to deliver the critical CSS based on the requested page:

  1. A build task which generates the critical CSS.
  2. Logic to find the page-matching critical CSS file.
  3. Output the critical CSS inline in the <head> section.

I skip the details on how your development environment might look like and go straight to the important parts, because the workflow is adaptable to almost any technology-stack. In my example, I’m using a WordPress instance served by Vagrant which resembles the later production environment.

{•••}
{•••}

Oh hey, ein neues Format auf dieser Seite.

Statt täglich oder eher unregelmäßig einzelne Sachen zu dokumentieren – und so noch mehr Noise in die Kanäle zu bringen – gibt es ab sofort eine wöchentliche Ausgabe mit Kram den ich die Woche über als interessant einstufe, oder der sonst irgendwie passiert ist.

Da ich selbst Fan derartiger Beiträge bin und gerne mal wieder ein paar Worte in dieses Fenster hier eingeben möchte, die nicht nur aus Code bestehen, gibt es nun eine Retrospektive in dieser Form. Genug begründet, nachfolgend Ausgabe 1.

{•••}

Wer PHP-basierte Webseiten ausliefern möchte, hat mittlerweile eine Menge Möglichkeiten, viele werden den Wechsel von Apache zu nginx in Kombination mit PHP-FPM bereits hinter sich haben, welcher bereits einen ansehnlichen Performance-Vorteil gebracht hat.
Durch den Einsatz von HHVM und dessen JIT-Compiler (vs. konventionellem PHP Interpreter) lässt sich im Zusammenspiel mit nginx ein weiterer großer Schritt in Sachen Performance machen. Ein netter Nebeneffekt ist die Tatsache, dass sich auch starkfrequentierte Anwendungen auf vergleichsweise günstiger Hardware betreiben lassen.

Wie man solch einen Server zusammenbaut, gibt es im nachfolgendem Tutorial, kurz und bündig samt beispielhafter WordPress Instanz. Das ganze passiert bei DigitalOcean auf einer Ubuntu 14.04 LTS Maschine.

{•••}

The newest iteration of my 2012 wallpaper Polylog. This version is made to be used on displays up to 5K such as the newest iMac, but it looks also great on lower resolution screens.

The package also includes a ready to use iPhone 6 (Plus) version, which should be big enough to work great on other phones as well.

Heute gibt es mal wieder ein kleines Update hier in eigener Sache, da ich in den letzten Monaten einfach eine Menge zu tun hatte und zu nichts kam was die Schreiberei angeht und auch niemanden mit Zeug langweilen wollte, welcher niemanden interessiert. Egal, nachfolgend einige Dinge die passiert sind.

WordPress, Jekyll, Middleman?

Wer eine Webseite betreibt, kennt diese Grundsatzfrage die einem von Zeit zu Zeit in den Sinn kommt: Welche Plattform will ich eigentlich nutzen und ist die aktuelle die passendste? Nicht anders war es auch als ich anfing dieser Seite ein Facelift zu verpassen.

Ganz oben auf meiner Liste standen die Static Site Generators, namentlich Jekyll und dessen Ruby on Rails-artiger Bruder Middleman, in die man Markdown und ‘HTML+CSS-Backformen’ wirft und sich eine statische HTML-Seite backen lässt, die man anschließend günstig auf Amazon S3 oder kostenlos auf GitHub Pages hosten kann.

Jedoch entschied ich mich gegen das verlockend klingende Angebot den Overhead den WordPress mit sich bringt abzuwerfen und wollte stattdessen meinen bisherigen Stack optimieren, um so eine ähnliche Performance zu erreichen wie die statischen Kollegen. Auch wollte ich nicht auf diverse WordPress Funktionen verzichten die man eben seit Jahren gewohnt ist. An dieser Stelle ein Verweis auf das wohl beste WordPress Plugin: Advanced Custom Fields.

Development & Deployment

Wo ich schon einmal dabei war hinter den Kulissen umzubauen habe ich auch gleich meinen bisherigen Workflow etwas angepasst und wechselte z.B. von Grunt zu gulp.js und tauschte aufgeblasene Icon-Fonts durch ein SVG Sprite aus, welches von gulp-svg-sprites aus einzelnen SVG-Icons zusammengebaut wird. Wie üblich gibt es noch zahlreiche andere Änderungen (Hallo Refactoring und Optimierung) die aus Erfahrungswerten resultieren, aber damit könnte / werde ich denk ich ein anderes Mal einen kompletten Artikel füllen. Also weiter im Text.

Weil “Daten via SFTP vom Computer auf den Server ziehen” dank Git und massig Deployment-Lösungen nicht mehr angebracht ist, hab ich Capistrano in meinen Workflow integriert, welches den wünschenswerten “One Command Deploy” bringt, heißt: Commits zu GitHub pushen, cap production deploy und binnen Sekunden sind die Änderungen live. Für Notfälle gibt es auch noch die Option eines Rollback zur vorherigen Version.

Da ich sowieso vor hatte meine Host Europe vServer nach und nach zu DigitalOcean1 umzuziehen konnte ich so direkt einmal HHVM mit nginx aufsetzen und es im Production-Einsatz testen. Der Performance-Gewinn ist wirklich erheblich, ohne jetzt Zahlen und Statistiken auspacken zu wollen, die man im Web zu genüge findet. Das kombiniert mit Caching ist wohl die aktuell schnellste Technik, WordPress und generell PHP-basierte Anwendungen auszuliefern.

+ About Seite

Was ist schwieriger als eine Seite über die eigene Person zu bauen und mit Texten über sich selbst zu versehen? Richtig, eine Seite über sich selbst zu bauen. Zumindest war das mein Empfinden, als ich nach Ewigkeiten fertig war eine About-Page zusammenzuwürfeln, welche meine Tätigkeiten grob abbildet.2

+ Fotos (Kategorie)

Eine weitere Änderung erfuhr die Foto Kategorie, welche bisher lediglich die Beiträge einschloss, welche in entsprechender Kategorie lagen. Unvorteilhaft für meine Anforderungen.

Problem: Ich schreibe z.B. ein Review zu irgendetwas und streue dort Fotos mit ein, aber diese werden nie in der Foto-Kategorie gelistet, da es sich eben um kein reinen Foto-Beitrag handelt und ich nur ungern die Kategorie mit Reviews belege. (Stay on Topic!)

Lösung: Attachments (ein WordPress Post Type) mit Kategorien versehen und diese in den WP Query der Archivseite einschließen. Dann noch ein passenderes Layout dazu entwerfen und fertig ist die Foto-Seite.

So viel für den Moment, ich habe vermutlich zig Sachen vergessen zu erwähnen, wollte diese Sache aber endlich abschließen und es gibt ja immer noch die Möglichkeit, weitere Beiträge zu schreiben. In diesem Sinne.


  1. Ref-Link. Betreibe seit Anfang 2014 dort Server für diverse Sachen und kann DigitalOcean mit dem Amsterdam-Standort wirklich sehr empfehlen. 
  2. Die Zielgruppe der About-Page ist auch nicht der Endbenutzer die ich freiberuflich akquirieren möchte, sondern vielmehr die Personen, die andere Personen einstellen. Daher Buzzword-reichhaltig.