CSS, HTML und Javascript mit {stil}

CSS optimieren: kurze Ladezeit, schneller Seitenaufbau

CSS optimieren und komprimieren

Im Sinne einer geringen Page Load oder kurzen Ladezeit und für einen schnellen Seitenaufbau müssen wir CSS optimieren, reduzieren und komprimieren.

Vor allem die mobilen Geräte sollen mit schnellem und leistungsfähigen CSS versorgt werden.

CSS-Dateien gehen im Handumdrehen auf wie ein Hefekuchen. Gleichzeitig übernimmt CSS immer mehr Aufgaben von Javascript.

Selektoren sind unterschiedlich effizient. Ein id-Selektor greift schneller als ein class-Selektor. Am Ende der Skala rangieren Pseudo-Selektoren, bei denen die Browser am längsten brauchen, bis das Element identifiziert und aufgehübscht ist.

CSS Selektoren nach EffizienzidclassTypAdjacentChildDecendantUniversalPseudo#flag.menup, h1, lih2+pdiv>tableul a*a:hover

In der Praxis ist der Geschwindigkeitsunterschied zwischen id- und class-Selektoren gering. Viele Experten raten zum Verzicht auf id-Selektoren zugunsten von Klassen-Selektoren, denn Klassen-Selektoren können wiederverwendet werden. id-Selektoren dürfen nur einmal innerhalb der HTML-Datei benutzt werden. Also braucht ein einzelnes Element der Seite eine ganze Zeile CSS für sich allein. Das kann den Geschwindigkeitsvorteil unterwandern.

Das heißt nun nicht, dass alle id-Selektoren aus dem HTML herausgeworfen werden sollten, denn Javascript profitiert von id-Attributen.

CSS für die Performance

Bei umfangreichen Webprojektiven kommen schnell 50 bis 100 KB durch CSS-Dateien zusammen. Vor allem die Templates von Content Management Systemen – allen voran WordPress – geizen nicht mit Stil bis in die letzte kleine Ecke. Aber nicht nur die Größe der CSS-Datei ist ein wichtiger Faktor, sondern auch eine performante Schreibweise.

CSS Labyrint
CSSLint erstellt eine Analyse der CSS-Datei. Nicht, dass man sich nun jede Warnung gleich zu Herzen nehmen muss: Jeder nach eigenen Ansprüchen.

Inline-Stile und style-Tag vermeiden

Inline-CSS und style-Tags erschweren die Pflege und Erweiterung der Stylesheets, es sei denn, es handelt sich um wirkliche Ausnahmen.

<style>
    h1 { font-size: 1em; }
</style>

<h1 style="font-size: 1em"></h1>

Aber das wussten wir sowieso schon seit langem …

Dennoch kann ein style-Tag im Head der Seite Sinn machen: Wenn der sichtbare Anfang der HTML-Seite (Stichwort: Above the fold) mit inline-CSS versorgt wird, kann der Browser mit dem Aufbau der Seite beginnen, bevor die CSS-Datei(en) geladen sind.

Ein schneller Aufbau der Seite kommt insbesondere den Besuchern mit mobilen Geräten entgegen.

CSS-Dateien kombinieren

Für jede externe Resource – seien es Bilder, CSS- oder Javascript-Dateien – sendet der Browser einen HTTP-Request (Hypertext Transfer Protocol) an den Webserver. Jeder Request hat einen kleinen Overhead und verzögert den Aufbau der Seite.

Bevor die Seite veröffentlicht wird, werden einzelne CSS-Dateien zu einer CSS-Datei zusammengelegt. Jede einzelne CSS-Datei wird ansonsten zu einem HTTP-Request.

<link rel="stylesheet" href="reset.css">
<link rel="stylesheet" href="layout.css">
<link rel="stylesheet" href="modules.css">
<link rel="stylesheet" href="colors.css">
<link rel="stylesheet" href="fonts.css">

Damit dabei der Überblick erhalten bleibt, helfen ein paar Regeln für Organisation der CSS-Datei.

Links zu extern gehosteten Fonts

Auch die Links zu Webfonts sind separate HTTP-Requests. Folgt man dem Link, zeigt der Browser die CSS-Regeln für die gelinkten Fonts und diese Regeln können direkt in die alles umfassende CSS-Datei kopiert werden.

Besser sitzen die Font-Regeln sogar im style-Tag weit oben im Head der Seite, damit der Browser sofort auf sie zugreifen kann. Also, statt des von Google vorgefertigten Quicklink zur CSS-Datei

<link href='https://fonts.googleapis.com/css?family=Fira+Sans:400,300,500,300italic' rel='stylesheet' type='text/css'>

die Seite mit dem Font mit der URL aus dem Quicklink (https://fonts.googleapis.com/css?family=Fira+Sans:400,300,500,300italic) einmal im Browser aufrufen, um das CSS zu kopieren.

https://fonts.googleapis.com/css?family=Fira+Sans:400,300,500,300italic
@font-face {
   font-family: 'Fira Sans';font-style: normal;
   font-weight: 300;
   src: local('Fira Sans Light'), local('FiraSans-Light'), url(https://fonts.gstatic.com/s/firasans/v5/VTBnrK42EiOBncVyQXZ7j6RDOzjiPcYnFooOUGCOsRk.woff) format('woff');
} 
@font-face {
   font-family: 'Fira Sans';
   font-style: normal;
   font-weight: 400;
}

CSS-Kurzschriften und Gruppen verwenden

body { margin-top: 20px;
    margin-right: 10px; 
    margin-bottom: 5px; 
    margin-left: 10px; }
body { margin: 20px 10px 5px 10px }

CSS-Kurzschriften (Shorthand) vorsichtig verwenden

Unbedachte Shorthands wiederum können den Browser ins Schwitzen bringen.

.demo { background: gainsboro; }

Eigentlich soll hier doch nur die Hintergrundfarbe gesetzt werden. Was aber tatsächlich abläuft, ist Folgendes:

.demo {
   background-color: gainsboro;
   background-image: none;
   background-position-x: 0%;
   background-position-y: 0%;
   background-size: auto auto;
   background-repeat-x: repeat;
   background-repeat-y: repeat;
   background-attachment: scroll;
   background-origin: initial;
   background-clip: border-box; 
}

Kann man sich im Firefox-Inspektor unter den Regeln des Elements vor Augen führen lassen.

.demo { background-color: gainsboro } hingegen macht genau das, was es soll, und nicht mehr.

!IMPORTANT nur in höchster Not verwenden

!important hilft, wenn ein einfacher Selektor durch einen spezielleren Selektor überschrieben soll.

p, li { color: rgb(120,120,120) !IMPORTANT }
.extra { color: black }

Eigentlich sollte die Klasse .extra alles in Schwarz setzen, da sie spezifischer als p und li ist. Aber das !IMPORTANT verhindert die Anwendung von .extra. Nach einem halben Jahr haben wir das !important vergessen und suchen verzweifelt, warum die Klasse .extra keine Wirkung zeigt. !Important macht die Pflege der CSS unnötig schwer.

Überqualifizierung vermeiden

Das li ist überflüssig, wenn das a-Tag sowieso nur in li-Elementen vorkommt:

#nav li a 
#nav a

Das div vor .nav ist ebenfalls überflüssig.

div.nav { … }
besser
.nav {}

Absteigende Selektoren sind teuer.

blockquote p a span

Diese Konstruktion stammt aus der CSS-Datei des WordPress-Templates twentyfourteen:

.singular .site-content .hentry.has-post-thumbnail

Da haben die Tags der Templatedateien schon so viele Klassen, und dann wird ein Element über eine lange Kette von Vorfahren angesprochen. Das kostet viel Zeit beim Aufbau der Seite. Lieber so spezifisch wie möglich werden, denn solche Regeln sind schwer lesbar und schon eine Woche später nicht mehr nachvollziehbar.

Browser lesen Stile von rechts nach links und nicht von links nach rechts (Kontext-Selektoren und Performance) wie wir – dass sollte man sich immer vor Augen halten.

Universal Selektoren vermeiden

* { margin: 0; padding: 0; }

legt eine hohe Last auf den Browser, der jetzt erst einmal alle Elemente mit diesen Eigenschaften versorgen muss.

All you can eat macht dick und langsam

Das WordPress-Template twentyfourteen »wiegt« 75KB. Die meisten der Elemente werden nie benutzt.

Aber welcher Webdesigner hat die Zeit, die ungebrauchten Elemente zu entfernen? Die Templates der Kauf-Designs sind fast immer auf CSS-Resets und CSS-Frameworks aufgebaut und wiegen noch schwerer. Bevor man sich die Finger an Verbesserungen verbrennt, ist zumindest eine Minifizierung eine Wunderdiät für auswuchernde CSS-Dateien.

Online JavaScript/CSS Compression Using YUI Compressor

Writing efficient CSS

CSS Architectures: Refactor Your CSS

Average Page Weights Increase by 32% in 2013

CSS-Dateien verkleinern

Ein systematischer Aufbau der CSS-Datei hilft bei der Pflege und Erweiterung der CSS-Datei. Man könnte die WordPress-CSS-Datei style.css als Quasi-Standard für die Schreibweise bezeichen: Nahezu alle style.css-Dateien beginnen mit einem CSS-Reset, gefolgt von den Stilen für das Layout, gefolgt von den Stilen für Schriften, Listen, Bilder in der Reihenfolge, in der die Elemente auf der Seite liegen.

Die elegante Schreibweise mit neuen Zeilen für jede Eigenschaft und Einrücken am Anfang jeder Zeile bauscht die CSS-Datei auf. Während der Entwicklung und der Tests ist die luftige Schreibweise sinnvoll, aber wenn die Seite in Dienst gestellt wird, ist die Zeit für eine sinnvolle Kürzung oder Komprimierung gekommen.

CSS minifizieren

Um die CSS-Datei für kurze Ladezeiten kompakt zu halten, wird überflüssiger Weißraum gelöscht.

  • Alle Eigenschaften einer Regel in eine Zeile schreiben. Hinter dem Doppelpunkt und hinter dem Semikolon muss kein Leerzeichen stehen.
  • Das letzte Semikolon vor der schließenden geschweiften Klammer muss nicht sein und kann ebenfalls gelöscht werden.
  • Leere Zeilen und Kommentare werden gelöscht.
mark,
ins {
	background: #fff9c0;
	text-decoration: none;
}
… wird zu … 
mark,ins{background:#fff9c0;text-decoration:none}

Die Komprimierung reduziert die CSS-Datei oft um die Hälfte und mehr, ist aber auch fehlerträchtig, wenn sie manuell durchgeführt wird. Sicherer sind Tools für die Minifizierung der CSS-Datei.

Die CSS-Datei des WordPress-Themes Twentyfourteen ist 87KB groß. Nach der Minifizierung hat sie noch rund 60 KB, wird die CSS-Datei anschließend komprimiert, nur noch 10 KB.

»Helium CSS« lässt die Luft ab: Helium ist ein Javascript, das Seiten crawlt und unbenutzte CSS-Regeln findet. Auch Helium CSS wird besser mit Vorsicht auf eine Kopie der Seiten losgelassen.