WordPress: jQuery von Google laden
Google bietet mit seinem Service Google Libraries API Website-Betreibern an, APIs wie jQuery direkt aus dem CDN (Content Delivery Network) zu beziehen. Dateien, die in einem CDN gehostet sind, nehmen Last vom Server der eigenen Homepage und, sofern die Homepage auch aus dem internationalen Raum aufgerufen wird, werden aus dem Rechenzentrum übertragen, das dem Besucher geographisch am nähesten ist.
Anhand von folgendem Beispiel lässt sich WordPress dazu bringen, jQuery nicht mehr aus der eigenen Installation zu verwenden, sondern direkt auf die Google-Server zu verweisen.
Den Code fügt man am besten an den Anfang seiner functions.php, die man im Bereich Design -> Editor vorfindet.
if ( !is_admin() ) {
wp_deregister_script( 'jquery' );
wp_register_script( 'jquery', 'https://ajax.googleapis.com/ajax/libs/jquery/1.6.2/jquery.min.js', false, '1.6.2', true );
wp_enqueue_script( 'jquery' );
}
Erklärung:
wp_deregister_script deregistriert erst einmal jQuery.
Im Anschluss wird es mit wp_register_script und den Parameteraufrufen wieder registriert.
Abschließend wird jQuery mit wp_enqueue_script der Warteschlange der zu ladenden Scripte hinzugefügt.
Anbei noch ein kleiner Exkurs zum Thema wp_register_script:
<?php wp_register_script( $handle, $src, $deps, $ver, $in_footer ); ?>
$handle ist der Name mit dem das Script bezeichnet wird; $src gibt den Pfad zum Script an; $deps gibt an, ob das Script Abhängigkeiten hat, also z.B. erst jQuery geladen werden muss, bevor jQuery UI geladen werden kann; $ver übergibt die Version des Scripts; $in_footer bestimmt, ob das Script im Footer geladen werden soll oder nicht. Letzteres ist insofern interessant, da sich die Ladezeiten von Webseiten durch das Platzieren von Script-Aufrufen am Ende des Quelltextes optimieren lassen.
Facebook Community-Standards
Wurde ja auch mal Zeit, dass Facebook den Nutzern, die selbst nicht darauf kommen, wie man sich in den sozialen Netzen verhalten sollte (m.E. nämlich nicht wesentlich anders, als man sich auch im “realen” Leben gibt), einen Leitfaden an die Hand gibt, was auf Facebook gewünscht ist und was nicht.
Den Community-Leitfaden findet man hier:
Facebook Community-Standards.
WordPress schneller machen mit GZip
Gerade umfangreiche und textlastige Homepages können schnell zu “Code-Bergen” im zwei- bis dreistelligen KB-Bereich werden. Dabei sind Bilder, CSS- und JavaScript-Dateien noch gar nicht mit einberechnet.
Gerade für Nutzer mit schmalbandigen Verbindungen wie Mobilfunk etc. macht es daher dann schon einen Unterschied, ob eine Seite nun beispielsweise 150KB Code oder nur 40KB Code lädt.
Was viele nicht wissen ist, dass es sehr leicht ist, sein WordPress ohne große Plugin-Orgien mit HTTP-Kompression auszustatten. Die HTML-Inhalte werden dann vor der Übertragung zum Client on-the-fly komprimiert und bei Erhalt wieder entpackt. Natürlich bedeutet dies für beide Seiten einen geringfügig höheren Rechenaufwand, jedoch ist dieser in meinen Augen gerade im privaten Bereich eher zu vernachlässigen.
Neben dem Aspekt, dass der Nutzer nun weniger Code laden muss und somit die Seite tendenziell schneller zu Augen bekommt, spielt für Suchmaschinen die Qualität einer Homepage auch in Hinsicht der Aufrufdauer eine Rolle. Man kann also sagen, dass der Webmaster dadurch auch sein Ranking positiv beeinflussen kann.
Code und Einbindung
Im WordPress-Dashboard wählt man den Menüpunkt Design und anschließend Editor. In die Datei functions.php fügt man nun folgende Zeilen ein
if(extension_loaded("zlib") && (ini_get("output_handler") != "ob_gzhandler"))
add_action('wp', create_function('', '@ob_end_clean();@ini_set("zlib.output_compression", 1);'));
und speichert im Anschluss.
Um zu überprüfen, ob die Operation erfolgreich war, besucht man am besten noch schnell folgende Seite und gibt dort seinen WordPress-Blog ein.
In meinem Fall konnte ich die zu übertragende Datenmenge so immerhin um über 70% reduzieren.
Facebook FBML Tabs ersetzen
Es ist höchste Zeit Static FBML-Tabs durch iFrames zu ersetzen
Schon im März 2011 empfahl Facebook den Fanpage-Administratoren Ihre bestehenden Static FBML-Tabs durch iFrames zu ersetzen. Kurze Zeit später, am 11. März 2011, war das Hinzufügen neuer Static FBML-Tabs nicht mehr möglich.
FBML wird “deprecated”
Mit der Deprecation von FBML schaltet Facebook nach und nach Funktionen ab, um auf die neue API zu migrieren. Daher ließt man auch schon seit längerem im FBML-Eintrag der Developers Reference:
If you are building a new application on Facebook.com, please implement your application using HTML, JavaScript and CSS.
Davon ist auch die beliebte Static FBML-App betroffen. Zwar wird Facebook bestehende Installationen wohl noch eine Weile weiter unterstützen, jedoch ist nicht sicher, wie lange noch. Fest steht, dass Betreiber von Anwendungen bzw. eigenen Tabs ab Oktober 2011 sicherstellen müssen, dass ihre Inhalte auch über eine SSL-verschlüsselte HTTPS-Verbindung erreichbar sein müssen.
“Facebook iFrame-Tabs” ist das Zauberwort
Ein iFrame ist im Grunde nichts anderes als ein kleines Fenster innerhalb einer Website, durch das man auf eine andere Website schaut. Mit einem eigenen iFrame-Tab kann man innerhalb von Facebook Inhalte von seinem eigenen Webserver nachladen.
iFrames sind ein Fortschritt
Da man innerhalb seines iFrames nun herkömmliches HTML, CSS, JavaScript, PHP etc. einsetzen kann, ist man in der Gestaltung seines iFrames sehr frei und kann sich auch endlich auf das Entwicklungswerkzeug der eigenen Wahl konzentrieren, ohne sich durch FBML-Dokus durchkämpfen zu müssen.
Ein weiterer Vorteil ist in meinen Augen, dass man nun auch Trackingwerkzeuge der eigenen Wahl einsetzen kann, und somit z.B. genauer bestimmen kann, woher die Leute denn kamen, die sich für mein Gewinnspiel o.ä. interessiert haben.
Als eher marginal würde ich einschätzen, dass durch das Auslagern der Inhalte etwas Last von den Facebook-Servern genommen wird und so zu Stoßzeiten etwas mehr Kapazitäten für das Ausliefern von Katzenfotos bereitsteht. ;-)
Ein neues Design für matthias.goebel.biz
Nachdem ich nun seit mehreren Jahren diese Homepage betreibe, fand ich das alte Design dann doch ein wenig angestaubt und (wie sagt man so schön?) unsexy.
Bisher habe ich ein angepasstes CoffeeSpot-Theme benutzt und bin jetzt auf das schlanke und minimalistische Ari-Theme umgestiegen, welches direkt ab Werk mit unterschiedlichen Bildschirmgrößen, mobilen Devices wie Tablets und Smartphones zurechtkommt.
Das alte CoffeeSpot-Theme
Gerade die direkte Unterstützung für mobile Endgeräte war mir bei der Auswahl des neuen Designs wichtig, denn die Nutzung dieser nimmt bekanntlich weiter zu und somit ist es denke ich sinnvoll, die eigene Homepage zukunftssicher zu machen.