Ich habe schon in einem älteren Artikel zum Thema Social Media Buttons beschrieben warum ich der Meinung bin man sollte nicht alles via Plugin einbinden. Seit dem hat sich einiges getan. Twitter hat @anywhere und Facebook Open Graph veröffentlicht. Beides dient der einfacheren und umfangreicheren Integration des jeweiligen Dienstes in die eigene Seite. Heute soll es um die Einbindung des Facebook-Like-Buttons gehen.

Facebook Like Button ohne Plugin einbinden

Den Facebook Like Button kann man auf 2 Arten einbinden, via iFrame und via Facebook Javascript SDK. Ich bin selber nicht so der iFrame-Fan deshalb zeige ich euch hier die andere Variante.

Den Quelltext für das SDK bekommt Ihr von der Entsprechenden Developer-Seite, dass ganze sieht dann folgendermaßen aus:

<div id="fb-root"></div>
<script>
  window.fbAsyncInit = function() {
    FB.init({appId: 'your app id', status: true, cookie: true,
             xfbml: true});
  };
  (function() {
    var e = document.createElement('script'); e.async = true;
    e.src = document.location.protocol +
      '//connect.facebook.net/en_US/all.js';
    document.getElementById('fb-root').appendChild(e);
  }());
</script>

Der Teil sollte am besten ganz nach unten in der footer.php eures Wordpress-Templates. Eine Zeile über >/body< Den eigentlichen Button könnt Ihr euch auch direkt von der Facebook-Developer-Seite erzeugen lassen.

<fb:like href="http://www.homepagebewertung.de" show_faces="false"></fb:like>

Damit Ihr immer auf den aktuellen Post von Wordpress verweist, sollte der Button in die single.php des Templates und folgendermaßen abgeändert werden. (geändertes href)

<fb:like href="<?php the_permalink() ?>" layout="button_count" show_faces="false" width="150"></fb:like>

Nach Teil 1 “messen der Geschwindigkeit” und “serverseitige Komprimierung”, Teil 2 “Javascript und CSS Minify” und Teil 3 “Reduzierung von HTTP-Requests” ist das heute der letzte Teil (4).

Nutzung von CSS-Sprites

Die Verwendung von Sprites kommt aus der Zeit der 8bit Computerspiele hier wurden, um nicht ständig Bilder in den Speicher nachladen zu müssen, mehrere Bilder auf einem vereinigt und mittels Positionierung des einen im Speicher befindlichen Bildes genau der Bereich angezeigt der benötigt wurde. Vielleicht haben sich ein paar von euch mal die Skins von Winamp 2 angesehen auch hier wurden alle Elemente an bestimmten Positionen auf ein Bild gebracht.
Im Web können solche Sprites z.B. für Navigations-Buttons oder Icons eingesetzt werden. Bei einer Standard OL oder UL wird den einzelnen List-Items (LI) dann per CSS ein Hintergrund-Bild zugeteilt und entsprechend Positioniert. Hover-Stadien können so auch direkt mit in den Sprite eingebunden werden und man spart sich JavaScript.
Als kleines Beispiel habe ich hier folgendes Bild verwendet:

Die Einzelnen “Buttons” sind 64px breit und 40 Pixel hoch. Im Body wird eine einfache Liste erstellt:

<ol id="navigation">
   <li id="item1"></li>
   <li id="item2"></li>
   <li id="item3"></li>
</ol>

Das CSS beinhaltet allgemeine Angaben für die Listenelemente und dann die einzelnen Angaben für die Positionierung des “Normal”- und des “Hover”-Zustandes.

#navigation li {
   list-style: none;
   float: left;
   width: 64px;
   height: 40px;
   margin: 0 12px;
}
#item1 {background: url("css-sprite.png") 0 0 no-repeat;}
#item2 {background: url("css-sprite.png") -65px 0 no-repeat;}
#item3 {background: url("css-sprite.png") -130px 0 no-repeat;}
#item1:hover{background: url("css-sprite.png") 0 -41px no-repeat;}
#item2:hover{background: url("css-sprite.png") -65px -41px no-repeat;}
#item3:hover{background: url("css-sprite.png") -130px -41px no-repeat;}

Hier noch der komplette Quelltext als ZIP: hpbw.de css-sprites

In Teil 1 zu “Website Geschwindigkeit optimieren” haben wir uns um das messen der Geschwindigkeit und die serverseitige Komprimierung gekümmert in Teil 2 ging es dann um Javascript und CSS Minify, heute das nächste Thema.

Reduzierung von HTTP-Requests

Je weniger HTTP-Requests, also Serveranfragen, desto besser! Die Anzahl der parallelen Anfragen ist bei den Browsern i.d.R. Auf 2-4 pro Host begrenzt, deshalb sollten im ersten Schritt, möglichst viele CSS und Javascript-Dateien zusammengefassten werden. Bilder wie Icons oder Navigationsbuttons werden zur Optimierung zu Sprites verbunden und mittels CSS als Hintergrundgrafiken eingebunden (siehe Teil 4 ab 15.4. 14:00 Uhr).

Oft können jedoch nicht alle CSS und Javascript-Dateien zusammengefasst werden. Bei der Verwendung externer Frameworks sollte man deshalb auf ein Content Delivery Network (CDN) zurückgreifen. Die großen CDNs wie z.B. Google bieten sehr viele Frameworks und nahezu 100% Erreichbarkeit. Doch auch beim eigentlich simplen Einbinden von CSS und Javascript gibt es einiges zu beachten. Damit die parallelen HTTP-Requests überhaupt funktionieren, müssen im <head> zuerst alle externen CSS-Dateien und erst danach alle Javascript-Dateien eingebunden werden. Nur dann lädt der Browser tatsächlich parallel mehrere Dateien.

Die Einbindung von jQuey-1.4.2 über das CDN von Google könnte z.B. so aussehen: Dies habe ich auch im Artikel “Geolocation Overlay mit Googles Location API und jQuery” so verwendet.

    <script type="text/javascript" src="http://www.google.com/jsapi"></script>
    <script type="text/javascript">google.load("jquery", "1.4.2");</script>

Morgen um 14:00 Uhr erscheint Teil 4, der letzte Teil aus der Serie “Website Geschwindigkeit optimieren” mit dem Thema “Nutzung von CSS-Sprites”.

In Teil 1 zu “Website Geschwindigkeit optimieren” haben wir uns um das messen der Geschwindigkeit und die serverseitige Komprimierung gekümmert, heute das nächste Thema.

Javascript und CSS Minify / Compremieren

Um noch weiter zu optimieren, bietet es sich an verwendete Javascript- und CSS-Dateien von unnötigen Zeichen zu befreien. Dazu gibt es „Minify-Tools“ wie z.B. den YUI Compressor von Yahoo. Dieser hat den Nachteil den Code dauerhaft zu komprimieren sobald man nachträglich etwas editieren möchte muss man mit den unübersichtlich gewordenen Files arbeiten. Meiner Ansicht nach der Bessere Weg führt über das Google-Code Projekt Minfy. Minfy lässt sich ganz einfach im Root der Website anlegen und sorgt zukünftig für das komprimieren von allen gewünschten CSS und JavaScript Dateien. Um dabei nicht bei jedem Pageview den Minify-Prozess auszuführen werden die Daten gecached und auf veränderung geprüft. Der Entwickler hat so immer die sauber gegliederten Codezeilen, dem User wird alle in komprimierter Form angeboten.

Nach dem entpacken von Minfy solle man die Datei min/config.php aufrufen und in Zeile 43: $min_cachePath anpassen. Auf dieses Verzeichnis muss PHP Schreibzugriff haben! Unter min/builder befindet sich ein Script welches ein kleines Admin-Tool zum erzeugen des benötigten HTML-Codes erzeugt. Ich habe mir einfach die Snippets, die das Tool erzeugt, in Typinator angelegt und lasse das builder-Verzeichnis einfach weg.

<!-- Minify CSS -->
<link type="text/css" rel="stylesheet" href="/min/b=PATH_TO_CSS&amp;f=CSS-FILES-KOMMA-SEPARATED" media="screen" />
<!-- Beispiel: -->
<link type="text/css" rel="stylesheet" href="/min/b=layout-dateien/css&amp;f=positioning.css,beautify.css" media="screen" />
<!-- Minify JavaScript -->
<script type="text/javascript" src="/min/?b=PATH_TO_JS_DIR&amp;f=JS-FILES-KOMMA-SEPARATED"></script>
<!-- Beispiel: -->
<script type="text/javascript" src="/min/?b=layout-dateien/js&amp;f=common.js,bigfeature.js"></script>

Morgen um 14:00 Uhr erscheint Teil 3 mit dem Thema “Reduzierung von HTTP-Requests”.

Nachdem Google am 9. April bekannt gegeben hat, die Ladegeschwindigkeit nun offiziell mit in das Ranking einfließen zu lassen wird dieses Thema noch wichtiger. Aber natürlich sollte man immer ein Auge auf die Ladegeschwindigkeit der Seite haben. In diesem ersten Teil wird es um die Messung der Geschwindigkeit und das serverseitige Komprimieren gehen. In Teil 2 kümmere ich mich um JavaScript und CSS Minfy, in Teil 3 um das reduzieren von HTTP-Requests und in Teil 4 schliesslich um CSS-Sprites. Die einzelnen Teile werden in den kommenden 3 Tagen jeweils um 14 Uhr veröffentlicht.

Jetzt also zum Teil 1, “Geschwindigkeit messen” und “serverseitige Komprimierung”.

Geschwindigkeit messen.

Zum messen der aktuellen Geschwindigkeit stehen mit Yslow und PageSpeed, beides Firefox Erweiterungen die auf FireBug aufsetzen, zwei kostenlose Tools zur Verfügung. Da die Geschwindigkeit natürlich auch von äußeren Faktoren beeinflusst wird, sollte man den Test mehrmals ausführen und den Mittelwert zum späteren Vergleich heranziehen.

Serverseitige Komprimierung

Ein erster großer Zugewinn wird erreicht, in dem die zu übertragenden Daten minimiert werden. Hierfür bietet Apache zwei Module (mod_deflate & mod_gzip), welche ohne Änderung an der eigentlichen Website, aktiviert werden können. Dazu editiert man die .htaccess im root der Seite.

Im Fall von aktiviertem mod_deflate:

	SetOutputFilter DEFLATE

Im Fall von aktiviertem mod_gzip:

mod_gzip_on Yes
mod_gzip_dechunk Yes
mod_gzip_item_include file \.(html?|txt|css|js|php|pl|jpg|gif|png)$
mod_gzip_item_include handler ^cgi-script$
mod_gzip_item_include mime ^text/.*
mod_gzip_item_include mime ^application/x-javascript.*
mod_gzip_item_exclude mime ^image/.*
mod_gzip_item_exclude rspheader ^Content-Encoding:.*gzip.*

Diese Maßnahme bringt schon den ersten großen Geschwindigkeitsschub.

Weiter dann ab morgen mit Teil 2 “Javascript und CSS Minify”

Vor kurzem habe ich ein neues Projekt fertiggestellt (http://www.sae-alumni.org) welches anfangs nur für Deutschland, Österreich und die Schweiz ausgeliefert werden soll. Alle anderen Länder bekommen ein Overlay, wie bei den Lightboxes, zu sehen und können dann auf Ihre lokalisierte Version wechseln.

Das ganze ging mit jQuery und Googles Location API sehr schnell und einfach!

Für das Overlay habe ich das jQuery-Plugin Simplemodal verwendet, mit diesem kann man einfach Overlays erzeugen.
Sollte noch kein jQuery eingebunden sein empfehle ich den Weg über Googles “Contend Delivery Service” und die jsapi. Außerdem binde ich gleich Simplemodal mit ein, den Pfad muss man natürlich anpassen.

<script type="text/javascript" src="http://www.google.com/jsapi"></script>
<script type="text/javascript">google.load("jquery", "1.4.2");</script>
<script type="text/javascript" src="jquery.simplemodal-1.3.3.min.js"></script>

Zum testen könnt Ihr folgendes CSS von SimpleModal verwenden und dann anpassen:

 /* Overlay */
#overlay {background-color:#000; cursor:wait;}
 
/* Container */
#container {width:580px; height:400px; font-family:Verdana, Arial; font-size:16px; text-align:left;background: #000;text-align:center;}
#container .contact-content {background-color:#333; color:#ddd; height:40px;}
#container a:link,
#container a:active,
#container a:visited,
#container a:hover{color:#fff;}
#container a.modal-close,
#container a.modal-close:link,
#container a.modal-close:active,
#container a.modal-close:visited {text-decoration:none; font-weight:bold; font-size:1.2em; position:absolute; top:-4px; right:6px; color:#999;}
#container a.modal-close:hover {color:#9bb3b3;}

Jetzt noch das Javascript mit Googles Location-API einbinden. In meinem Fall habe ich geprüft, ob der Client nicht aus DE, AT oder CH kommt. Zur Abfrage können alle ISO-3166-1 Codes verwendet werden.

$(document).ready(function() {
   if (google.loader.ClientLocation) {
     var loc = google.loader.ClientLocation;
     var countryCode = loc.address.country_code;
     if(countryCode != "DE" && countryCode != "AT" && countryCode != "CH"){
        $('body').append("<div id="overlay">Visible for other Countries</div>");
        $("#overlay").modal({
            closeHTML: "<a class="modal-close" title="Close" href="#">x</a>",
            position: ["15%",],
            opacity:80,
            overlayId: 'overlay',
            containerId: 'container',
            onClose: container.close
        });
     }
   }
 });
 
var container = {
	close: function(dialog){
		$("#overlay").remove();
		$("#container").remove();
	}
}

Jetzt noch das div#overlay aus obigen JavaScript mit dem entsprechenden Inhalt füllen, fertig.

Super gemacht! Ein Vergleich der aktuellen jQuery 1.4.2 und der YUI3 Syntax, inkl. kurzer Erläuterungen.

Nicht schlecht, hier die Dokumentation von jQuery zum lokalen öffnen als CHM-Datei.

Mit rund 60 Bugfixes schlägt das release 5.3.2 von PHP auf. Wir können so langsam gespannt sein wann die Provier auf den 5.3-Zug aufspringen und es in Koexistenz mit 5.2 anbieten.

Guter Artikel von PHP Gangsta, setzt zwar die Extension FileInfo voraus, diese ist aber seit PHP 5.3 Standard, für die Zukunft also ne klasse die man aus der Snippet-Kiste ziehen sollte.