WordPress: die CSS-Datei des Child-Themes performance-freundlicher einbinden

<style type="text/css">
    @import url('style.css');
</style>

<link rel="stylesheet" type="text/css" href="style.css" />

<?php
/*
 * 'Verhindere' @import CSS für WordPress-Child-Themes
 * und binde die CSS-Dateien per <link /> ein
 * Siehe: http://www.stevesouders.com/blog/2009/04/09/dont-use-import/
 * gefunden auf: http://calendar.perfplanet.com/2012/using-nginx-php-fpmapc-and-varnish-to-make-wordpress-websites-fly/
 */
if(is_child_theme()) {
    echo '<link rel="stylesheet" href="';
    autoVer(get_bloginfo('template_url').'/style.css');
    echo '" />'."\n\t\t";
    echo '<link rel="stylesheet" href="';
    autoVer(get_bloginfo('stylesheet_url'));
    echo '" />'."\n";
} else {
    echo '<link rel="stylesheet" href="';
    autoVer(get_bloginfo('stylesheet_url'));
    echo '" />'."\n";
}
?>

9 Kommentare

1. Leider ist deine vorgeschlagene Lösung auch falsch. Zumindest, was das Platzieren dieser Sache angeht:
   

   Das sollte in WP immer mit dem Action Hook wp_enqueue_scripts erfolgen und dessen zugehörigen Funktionen wp_enqueue_script, wp_enqueue_style etc.

   Prinzip: Stylesheets & Skripte registrieren, dann einhängen. Damit können sie auch mal ausgehängt werden, falls nötig (z.B. von Plugins). Außerdem prüft WordPress schön alle Abhängigkeiten. Das wäre zusammen mit deinen Bedingungsabfragen dann der sauberste Weg.

   Funktionieren tun alle 3 Varianten, wobei die Linkmethode schon bei Javascripten wieder extreme Fehler verursachen könnte (aufgrund der Abhängigkeiten etc.).

   Daher sollte man immer und überall die Enqueue-Methoden empfehlen.

2. …hat meinen Code oben rausgehauen, ich meinte das hier:
   link rel=”stylesheet” type=”text/css” href=”style.css”

3. Hm…ich binde die nie im Head des Childthemes ein, sondern in der CSS Datei des Childthemes, wie es der Codex auch empfiehlt.

   http://codex.wordpress.org/Child_Themes#Example_of_a_basic_Child_Theme

   1. @Michael,

      und genau darin liegt das Performance-Problem → @import.

4. Das hab ich schon verstanden, aber es ist halt die von WP empfohlene Variante. Jetzt kann man sich überlegen, was man macht. Evtl. ein paar Milisekunden mehr Performance rausholen, oder der offiziellen Empfehlung folgen.

   Ist irgendwie ne Zwickmühle 😉

5. Der Lösungsansatz ist ziemlicher Kappes. Diese ziemlich aufwendige if-Abfrage zu verarbeiten – die Funktionen is_child_theme(), get_bloginfo(‘template_url’) bzw. autoVer(get_bloginfo(‘stylesheet_url’) müssen ja auch erstmal durch WordPress laufen und sie geben ja dann immernoch nur ein link-Element aus und dann wird die passende Datei erst geladen – sind im Leben nicht performanter als die Lösung mit @import.

6. Wobei nach meiner Kenntnis die Performance-Einbußen absolut minimal sind, wohl nur Tausendstel… Natürlich behauptet da auch jeder was anderes in den einschlägigen Blogs etc., je nach “Glaubensrichtung”.

   Interessanter finde ich den Hinweis, dass es nach der Bewertung von Google Page Speed eine Rolle spielt, dass durch @import ja auch ein HTTP-Aufruf erfolgt — den man sich lieber sparen sollte.

   Beispiel:
   Bei Genesis Child Themes wird daher in der Regel so verfahren, dass alle Stile des Eltern-Themes erstmal ins Child Theme kommen (Genesis Parent und das Sample Child haben identisches CSS) und je nach Child Theme dann entsprechend weggekürzt wird (weil evtl. das Child nur 1 Sidebar hat etc.) oder eben geändert wird – oder notfalls auch ergänzt, z.B. eine neue Farbvariante. Spart HTTP-Aufrufe sowie Redundanzen und ist aus meiner Sicht pflegeleichter (da man sich auch ständiges “!important” spart).

   Problem wäre aber so oder so die Verwendung von Google Webfonts, wenn man die nicht auf den eigenen Server legen möchte, dann ist @import dennoch die simpelste Lösung – und für viele User auch die verständlichste.

   Dennoch wäre es nach Coding Standards (und zwecks Einhängen/ Aushängen via Hooks) die beste Lösung, diese dann über ein kleines Funktionöchen über den offiziellen Skript-/ Stil-Hook hinzuzufügen.

   Diese pöhsen Performance-Einbußen sind in Zeiten von guten Servern, gutem Caching (APC & Co., bzw. gute WP Plugins dafür) meines Erachtens zwar wichtig, aber nicht extrem. Einsparen von HTTP-Aufrufen sowie Kompression von Skripten und Stilesheets bringt viel mehr. Und vor allem: schauen, ob ein Plugin oder Themen seinen ganzen Krempel überall lädt, da kann man mitunter sehr viel rausholen, wenn man evtl. schlechten Code so eindämmt, dass JS & CSS nur geladen werden, wenn wirklich gebraucht.

7. Genau. CSS-Sprites fürs Design sind auch noch so ein Thema, für das man ruhig etwas Zeit investieren kann. Bei WordPress kommen ohnehin schnell ziemlich viele Grafiken zusammen, wie man an den ganzen Avataren, Smilieys, Werbebanner etc. auf dieser Seite bewundern kann.

8. Der Grund, wieso David mit seiner Empfehlung zur Verwendung von wp_enqueue_style absolut() recht hat: Man kann damit z.B. ein Plugin wie WP-Minify einsetzen um alle CSS-Dateien des Themes und aller aktiven Plugins zu einer großen CSS-Dateien zusammenfassen und komprimieren.

   Dadurch erspart man dem Nutzer einige HTTP-Requests, dieser eine Request ist auch noch kleiner als die Summe der einzelnen, da HTTP-Header nicht doppelt gesendet werden und man die CSS komprimieren kann und zuletzt kann über einen gut gesetzten Cache-Header die CSS-Datei sehr lang vorgehalten werden. Bei mehrfachen Seitenaufrufen spart man also sehr viele Requests.

   @Michael Oeser: Der Codex ist eher darauf ausgelegt, es einem Einsteiger so einfach wie möglich zu machen. Die Beschriebene Methode erfordert noch nicht einmal PHP-Kenntnisse. Aber nur weil sie einfach ist (und aus diesem Grund empfohlen wird) heißt es nicht, dass sie optimal ist, was sie eben auf keinen Fall ist.

Kommentare sind geschlossen.