Seite wählen

NETWAYS Blog

SASS – so macht CSS wieder Spaß

Keiner weiß, wie viele Entwickler schon aus dem Fenster gesprungen sind, weil sie „mal eben schnell“ alle Vorkommnisse eines Grautons und dessen Abstufungen leicht ins bläuliche Färben sollten. CSS wird zwar um viele Features erweitert, doch die Auzeichnungssprache an sich hat sich seit 1998 kaum geändert. Features wie Variablen sucht man vergebens, was einem bleibt ist viel doppelte Arbeit.
Doch bevor nun alle Entwicklungsabteilungen ins Erdgeschoß verlegt werden, möchte ich den Ausweg aus der misere Vorstellen: SASS.
*.sass Dateien sind spezielle Stylesheets, die über einen Compiler einfach in CSS umwandelt werden. Man kann so Variablen, verschachtelte Definitionen, Funktionen und vieles mehr in sein Stylesheet einbauen – der Compiler erstellt daraus dann eine valide CSS-Datei.
Und das beste: Wer CSS kann, muss kaum Neues lernen. Eigentlich kann man damit sofort produktiv loslegen.
Nehmen wir mal ein einfaches Stylesheet:

div.header {
   background-color: #ababab; /*dunkelgrauer Rand*/
   border: 1px solid #dedede; /*grauer Rand*/
}

Mit SASS würde dies wie folgt aussehen:

$theme_color1: rgb(222,222,222) /*Variable mit Farbwert*/
div.header
   background-color: darken($theme_color1, 20%) /*Rand, dank Funktion 20% dunkler als $theme_color*/
   border: $theme_color1 /*grauer Rand*/

Der Vorteil ist sofort ersichtlich: Muss man bei einem neuen Grauton das CSS  an zwei Stellen ändern und sogar den neuen Farbwert des Randes per Hand ausrechen, reicht bei der .sass Datei lediglich eine Änderung in der Variable $theme_color – den Rest erledigt SASS.
Das CSS erstellt man einfach via

sass --watch %sass-quelle%:%ziel-datei% 

Durch den –watch Parameter erkennt SASS, wenn sich Änderungen an der *.sass Datei ergeben haben und aktualisiert das CSS. So kann man direkt am SASS Entwurf arbeiten und sieht das Ergebnis sofort.
Natürlich ist das nur ein kleiner Einblick in die Möglichkeiten. Am besten einfach mal auf die Homepage gehen, ausprobieren und begeistert sein.

Serie High Performance Websites – Zusammenfassung

LogoZusammenfassung der Serie über High Performance Websites.
In dieser Artikelserie haben wir versucht einen kurzen Einblick in die Optimierung von Server, Sourcecode und Infrastruktur in Bezug auf Performance zu geben.
Für Feedback oder Anregungen sind wir selbstverständlich jederzeit offen und freuen uns über jede Kontaktaufnahme.

Serie High Performance Websites – Teil 5: letztes Feintuning

Dieser vorerst finale Teil befasst sich mit den restlichen Serverseitigen Themen Redirects und Keep-Alive. Zusätzlich wird auf DNS und das DNS Cacheverhalten des Browsers eingegangen.
Für die Performance von Webseiten hat DNS ausschließlich beim erstmaligen Aufruf Einfluss. Hier ist zu beachten das der DNS Server ihres ISP typischerweise 10-200 Millisekunden braucht um eine Namensauflösung durchzuführen. Nach der Erstanfrage wird der DNS Eintrag sowohl im Betriebssystem als auch im Browser gecached um erneute Anfragen zu vermeiden. Wie lange der bereits erfragte Eintrag zwischengespeichert wird gibt in erster Linie die TTL (Time-To-Live) in der DNS Zone an, desweiteren ist in den Browsern hinterlegt wie lange der DNS Cache zusätzlich zur TTL Einträge speichern soll. Dies kann bedeuten das trotz bereits abgelaufener TTL ein DNS Eintrag im Browser noch durch den Cache vorgehalten wird.
In Summe kann festgehalten werden das es sinnvoll ist die Verwendung unterschiedlicher Hostnamen auf ein minimum zu reduzieren um die durch DNS Anfragen entstehende Latenz beim erstmaligen Laden der Seite zu reduzieren.
In den vorherigen Kapiteln wurde vieles unternommen um die Ladezeit für den Benutzer so gering wie möglich zu halten. Genau das Gegenteil verursachen leider verwendete Redirects, wird bei der ersten HTTP Anfrage ein Redirect vom Server erwidert folgt daraus ein erneuter (also zusätzlicher) HTTP Request. Dieses Verhalten verzögert das Laden der eigentlichen Seite und sollte vermieden werden.
Ziel ist also Redirects wenn möglich zu verhindern oder sehr eingeschränkt zu verwenden.
Zur weiteren Optimierung sollte Keep-Alive serverseitig aktiviert werden, hier werden vom Browser bereits offene TCP Verbindungen für einen definierten Zeitraum wiederverwendet. Dieser Mechanismus spart zusätzlich Zeit für den eigentlichen TCP Verbindungsaufbau. Der Server und Browser signalisieren beim initiieren der Verbindung im „Connection“ Header ob Keep-Alive Verbindungen erlaubt sind. Zusätzlich zu Keep-Alive wird unter HTTP/1.1 Pipelining zur Verfügung gestellt um die Verbindungsgeschwindigkeit zu erhöhen. Hier werden mehrere Anfragen über einen Socket übermittelt ohne vorher auf eine Antwort des Servers warten zu müssen.
In Apache wird Keep-Alive durch die folgenden Direktiven aktiviert.

Keep-Alive on

Serie High Performance Websites – Teil 4: Weniger ist Mehr !

Ein weiterer wichtiger Punkt bei der Optimierung ist das Thema Kompression, hierbei werden sämtliche noch komprimierbaren Inhalte (HTML, CSS, JavaScript, …) geschrumpft und so in einer verkleinerten Version ausgeliefert.
Die durchschnittliche Einsparung durch Komprimierung beträgt bis zu 70% was bedeutet das nur 30% des ursprünglichen Dateiinhaltes übertragen werden müssen. In den meisten Setups wird „gzip“ für die Verkleinerung der ܜbertragungmenge verwendet, gzip bietet hier eine bessere Komprimierungsrate als „deflate“.
Um die Komprimierung in Apache zu aktivieren muss mod_deflate geladen werden, zusätzlich zum laden des Moduls muss in der VirtualHost (oder globalen) Konfiguration die Kompression aktiviert werden.

AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css application/x-javascript

Zusätzlich lässt sich mit dem Parameter DeflateCompressionLevel der Komprimierungsgrad festlegen, die Grundeinstellung ist hier meist ausreichend.
Einige ältere Browserversionen unterstützen leider keine Kompression, deswegen sollten zusätzlich folgende Einstellungen hinterlegt werden um auch diesen „Exoten“ Zugang zur Webpräsenz zu ermöglichen.

BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4\.0[678] no-gzip
BrowserMatch \bMSIE !no-gzip !gzip-only-text/html

Durch die nun gesetzten Einstellungen werden sämtliche „textuellen“ Inhalten wie HTML/CSS oder JS ab jetzt komprimiert übertragen. Im nächsten Teil wird nun noch angeführt wie mittels DNS, Keepalive und der vermeidung von Redirects noch zusätzlich Ladezeit verkürzt werden kann.
Analog hierzu ist die Konfiguration unter Lighttpd, das „deflate“ Modul ist vollständig unter http://redmine.lighttpd.net/projects/lighttpd/wiki/Mod_Deflate dokumentiert. Die Einrichtung ist hier denkbar einfach sofern Lighttpd mit Kompressionsunterstützung übersetzt wurde (sollte in allen Distributionspaketen Standard sein).

Serie High Performance Websites – Teil 3: Cachen erlaubt !

Nachdem im vorherigen Teil die HTTP-Requests auf ein minimum reduziert wurden ist es nun an der Zeit den Client das zwischenspeichern von Inhalten auf eine besitmmte Zeit hin zu erlauben.
Hierfür werden sog. Expires-Header serverseitig konfiguriert. Die dadurch in den HTTP-Response gesetzten  „Expires“ und „Cache-Control“ Header werden bei der Auslieferung jedes Contentelements übertragen. Definiert wird der Expires-Header auf Basis von Dateinamen oder Pfaden in der abgerufenen URL. Um die Expires in Apache nutzen zu können muss mod_expires aktiviert sein.
Für Lighttpd ist eine passende Anleitung unter https://redmine.lighttpd.net/projects/lighttpd/wiki/Mod_expire zu finden.
Zusätzlich ist es notwendig in der Konfiguration des entsprechenden VirtualHost’s folgende definitionen vorzunehmen:

<IfModule mod_expires.c>
ExpiresActive on
ExpiresByType image/gif "access plus 10 years"
ExpiresByType image/jpeg "access plus 10 years"
ExpiresByType image/png "access plus 10 years"
ExpiresByType text/css "access plus 2 years"
ExpiresByType text/js "access plus 2 years"
ExpiresByType text/javascript "access plus 2 years"
ExpiresByType application/javascript "access plus 2 years"
ExpiresByType application/x-javascript "access plus 2 years"
</IfModule>

Hier wird für die genannten Elemente jeweils eine Ablaufzeit von 10 bzw. 2 Jahren definiert, was den anfragenden Browser dazu bringt das geladene Element für 10 bzw. 2 Jahre im Browsercache zu halten und nicht erneut abzufragen.
Zusätzlich kann noch ein genereller Expire mittels
ExpiresDefault ”access plus 1 days”

gesetzt werden.
Durch dieses Verhalten ergibt sich allerdings ein neues Problem, beispielsweise kann es sein das sich innerhalb dieser 2 Jahre das Stylesheet verändert. In diesem Fall würde der Browser das veränderte CSS durch die ihm Bekannte „Cache-Halbwertszeit“ von 2 Jahren nicht neu laden und die Änderung würde nicht angezeigt. Um dieses Problem zu verhindert sollte eine Versionierung der „halbstatischen“ Elemente durchgeführt werden, aus „style.css“ wird so „style-20090101-001.css“.
Ändert sich nun das Stylesheet auf „style-20090101-002.css“ wird der Sourcecode der HTML Seite um den Namen des CSS angepasst und der Browser läd automatisiert die neue Version da ihm das „neue“ Inhaltselement nicht im Cache bekannt ist.