Praktisch: Nach erstem erfolgreichen Backup des Twitter-Streams erzeugt Backupify zusätzlich zu XML-Formaten ein PDF-Buch mit allen Tweets des Accounts. So steht einer Weiterleitung per E-Mail, einer Aufbewahrung auf lokalem Rechner oder einem Ausdruck auf Papier nichts mehr im Weg.

Für professionelle Anwender macht sich ein – noch in der Planung befindlicher – Upgrade des Accounts mit weiterem Speicherpotenzial bezahlt, Überzeugung und Begeisterung zum Online-Service vorausgesetzt.

Backup-Initialisierung für den Twitter-Stream
Nachfolgend werden die Schritte der Einrichtung für das Anlegen eines automatischen Backups für einen Twitter-Profil abgebildet und mit kurzen Notizen versehen. Es ist zu beachten, dass mit der Sicherung erst wenige Tagen nach der Einrichtung angefangen wird.

Nach dem Login werden unter “Settings” verfügbare Services gelistet

“Manage” erlaubt eine Verifizierung mit gewünschtem Twitter-Account

Sparsam angelegte Optionen werden am Fuß der Seite festgelegt

Im Bereich “Archives” werden angefertigte Sicherungen als XML angeboten

Auf Wunsch benachrichtigt Backupify über den Status per E-Mail

Fazit
Backupify zeigt sehr deutlich und gekonnt, dass Speicher im Web nicht nur mit herkömmlichen Dateien befüllt werden kann – Digitale Informationen aus Social-Netzwerken und Web 2.0 Diensten wie Flickr sind ebenfalls gegen Datenverlust empfindlich und eignen sich daher mehr als perfekt für das von Backupify konzipierte und umgesetzte Prinzip: Sichere alles, auch deine Aktivitäten im Social-Web.

Die aus der Praxis gewonnene Erkenntnis zeigt, dass Artikel mit gesetzten Pingbacks nicht selten über eine sehr kurze Lebensdauer verfügen und im Laufe der Zeit oft und gern offline gehen. Mögliche Gründe dafür: Blog eingestellt, Domain gewechselt, Artikelseiten entfernt etc. Die Folge: Man linkt im Kommentarbereich auf eine Blogseite, die es aktuell gar nicht mehr gibt. Nicht wirklich schön und ruft jeden passionierten Blogger zu Taten auf.

Referenzseiten landen im Nirvana

Miese Techniken: Redirects auf Schrott
Unangenehm dreist wird es, wenn scheinbar freundlich und gut gemeinte Referenzseiten mit funktionierenden Pingbacks plötzlich (meist nach einem Zeitfenster von 3 – 4 Monaten) auf Projekte mit pornographischen Inhalten umgeleitet werden, so dass man als normalsterblicher Blogger unbewusst auf nackte Tatsachen verweist, ohne davon jegliche Kenntnis zu nehmen. Auch Google sieht es nicht gern, wenn eine solide Blogseite mit unseriösen Angeboten verknüpft ist – Zack, Ranking runter. Da muss sich also etwas ändern!

Kontrolle der existenten Blogverknüpfungen
Nachfolgend stellt sich ein ausführbares PHP-Skript als eine der tauglichen Lösungen vor: Der Code untersucht die in der Datenbank aufbewahrten Trackbacks auf ihre momentane Erreichbarkeit und fahndet im eingelesenen Artikeltext nach dem Link zum Blog. Auf diese Weise können nicht nur “Leichen”, sondern auch “Betrüger” (= haben den Link zum Blog entfernt oder die Seite umgeleitet) im Nu ausfindig gemacht und aus dem Blog manuell entfernt werden.

Beobachtungen bestätigen: Bei circa 500 Pingbacks innerhalb eines Blogs sind alle 6 Monate grob überschlagen 5 – 7 % davon nicht mehr brauchbar, weil nicht existent.

Funktionsweise im Schnelldurchlauf
Um an die Auswahl der Pings (= Trackbacks und Pingbacks) heranzukommen, generiert ein SQL-Kommando die Liste mit URLs der Quellen, die wiederum vom Script nach und nach zwecks Check angesteuert werden. Verdächtige Adressen werden eingeblendet, entsprechende Trackbacks können z.B. im Backend in der Kommentaransicht mithilfe der internen (Kommentar-)Suche lokalisiert und bei Bedarf eliminiert werden.

1. Schritt: DB-Export als CSV
Zunächst gehören die Ursprungsadressen der Pings in Form von alleinigen URLs als lesbare Liste exportiert – sie wird später vom Skript eingelesen. Ein SQL-Befehl gibt den gewünschten Datensatz aus, dieser gehört händisch exportiert. Für das geplante Vorhaben kann ein beliebiger SQL-Client wie das Online-Tool phpMyAdmin oder die Desktop-Anwendung Sequel Pro angewendet werden. Einen Export als CSV ohne gesonderte Anpassungen schafft nahezu jede SQL-Applikation.

SQL-Statement zur Ausgabe der Ping-URLs:

SELECT DISTINCT comment_author_url
  FROM wp_comments
    WHERE comment_type
      IN('trackback','pingback')

Für alle Kommentartypen (Kommentare plus Pings):

SELECT DISTINCT comment_author_url
  FROM wp_comments

Hinweis zur Abfrage
Weicht der Tabellenname mit Kommentaren vom WordPress-Standard (wp_comments) ab, so ist dieser im Befehl zu korrigieren.

Export der ausgelesenen Daten im CSV-Format

2. Schritt: PHP-Code anpassen und speichern
Der nachstehende PHP-Code soll kopiert, im Editor eingefügt, in den beiden Zeilen nach dem ersten Kommentar (/* Zuweisung der Werte */) vervollständigt und abschließend als PHP-Datei, also mit der Endung .php, gespeichert werden.

Erläuterung der abzustimmenden Variablen:

• $import_file – Dateiname der erzeugten CSV-Datei
• $blog_url – Blog-Domain, nach der im Artikeltext gesucht wird

Quelltext der Minianwendung:

<?php
/* Zuweisung der Werte */
$import_file = 'customresult.csv';
$blog_url = 'playground.ebiene.de';

/* Import starten */
echo "Import läuft...\n";
$lines = file($import_file);

/* Keine Daten? */
if (empty($lines)) {
  die('No data');
}

/* URLs loopen */
foreach ($lines as $line) {
  /* Zeile scannen */
  preg_match('!"http://(.*)"!', $line, $matches);

  /* Keine gültige URL */
  if (empty($matches[1])) {
    continue;
  }

  /* Gültige URL */
  $url = 'http://' .$matches[1];

  /* URL abrufen */
  if (!$output = @file_get_contents($url)) {
    echo 'Unereichbar: '. $url. "\n";
  }

  /* Blog-URL suchen */
  if (!preg_match('/' .preg_quote($blog_url). '/i', $output)) {
    'Kein Link in: ' .$url. "\n";
  }
}

die('Fertig!');
?>

3. Schritt: Ausführen
Vorab: Die angelegte PHP-Datei und der exportierte Datensatz im CSV-Format befinden sich am gleichen Ort, also physikalisch im identischen Ordner. PHP-File ist ausführbar, CSV lesbar.

Vor dem Start wird der Ordner auf eine unter PHP-laufende Umgebung transferiert: Das kann ein entfernter oder ein lokal eingerichteter Server sein. Eine Initialisierung via Bash bietet sich an. Ein heimischer Server hat den wesentlichen Vorteil, dass dort Ausführungszeiten des Codes bei Bedarf angepasst werden können – denn je nach Anzahl der zu prüfenden Links kann der zeitintensive Check schon eine Weile dauern. Da heißt es: Kaffee holen.

Kommt es bei der Analyse der Adressen also zum Stop oder Fehlerhinweis, so muss entweder die Execution Time nach oben oder die Menge der Einträge innerhalb der CSV-Liste nach unten korrigiert werden.

Das erreichte Resultat: Suspekte Trackback-Quellen kommen als Übersicht zum Vorschein und können – doppelt hält besser – nach manueller Kontrolle aus dem Blog entfernt werden. The job is done.

Fazit
Je nach Projektgröße kann die Prüfroutine alle 6 Monate wiederholt werden – für mehr “Sauberkeit” in WordPress.

WordPress-Versionen + Anzahl der Blogs

• [3.0-alpha] => 5
• [2.9.2] => 461
• [2.9.1] => 440
• [2.9.0] => 84
• [2.8.6] => 177
• [2.8.5] => 66
• [2.8.4] => 206
• [2.8.3] => 25
• [2.8.2] => 20
• [2.8.1] => 19
• [2.8.0] => 46
• [2.7.x] => 252
• [2.6.x] => 87

Wie erwartet: Verbreitung nach Erscheinungsdatum

WordPress-Versionen + Anzahl der Blogs aus den Lesercharts

• [2.9.2] => 97
• [2.9.1] => 90
• [2.9.0] => 17
• [2.8.6] => 28
• [2.8.5] => 6
• [2.8.4] => 27
• [2.8.3] => 4
• [2.8.2] => 3
• [2.8.1] => 2
• [2.8.0] => 5
• [2.7.x] => 29
• [2.6.x] => 9

WordPress 2.9 in der Poleposition der (Lese)Charts

Dynamisches Konzept für Permalinks
Um die bereits gesetzten, aber im Laufe der Website-Entwicklung umgeformten Links nicht per Hand korrigieren bzw. migrieren zu müssen, werden Verknüpfungen zwischen den internen Blogseiten mithilfe eines simplen Shortcode gesetzt und mit jeweiliger ID angesprochen. Die Zweckmäßigkeit der Lösung: Die Artikel-ID bleibt für immer konstant, kann als Referenz der gelinkten Seite also sorglos verwendet werden – der Hyperlink wird anhand der ID dynamisch ermittelt und ist immer auf dem aktuellsten Stand. Ohne Weiterleitungen, ohne zusätzliche Plugins.

Erweiterung der functions.php im aktuellen Theme

add_shortcode(
  'post',
  create_function(
    '$atts, $data',
    'return "<a href=\"" .get_permalink($atts[id]). "\" title=\"" .esc_attr(strip_tags(get_the_title($atts[id]))). "\">" .$data. "</a>";'
  )
);

Mögliche Anwendung im Beitrag

... Text [post id=9]Verlinkter Blogartikel[/post] Text ...

Nennenswerte Vorteile

• Link (href) und Titel (title) stets up-to-date, da dynamisch geladen.
• Keine Migration oder Anpassungen bei URL-Änderung notwendig.
• Empfehlenswert für kleine bis mittelgroße Websites mit WordPress als CMS.
• Funktioniert bei Beiträgen, statischen Seiten und Anhängen.

Nachteile des Shortcodes

• Erzeugt zwei zusätzliche Datenbankabfragen, da Werte neu gelesen werden.
• Umständlich, da die Ziel-ID gefunden und händisch eingefügt werden muss.
• Bei der Entfernung des Codes bleiben Shortcode-Einträge sichtbar zurück.
• Keine interne Benachrichtigung via Pingback.

Voraussetzungen

• WordPress 2.8

Andere Route zum Ziel?
Als Alternative zum vorgestellten Ansatz wären relative Pfadangaben beim Verlinken der Beiträge durchaus denkbar – nach einem Blogumzug bliebe zumindest die Suchen-Ersetzen-Prozedur auf der Datenbankebene erspart, da sonst die alte Domain im Pfad durch die neue getauscht werden müsste. Wird jedoch die Gliederung der URL im Laufe der Zeit nachträglich korrigiert, so kommt man als Blogger nicht drumherum, “hart” gesetzte Links aufwendig zu aktualisieren. Des Weiteren kommen die meisten Feedreader mit relativen Angaben der Links im Artikelinhalt nicht klar – Contra für die Relativität also.

Fazit
Zusammenfasend lässt sich festhalten, dass die angesprochene Methode zwar geringfügig umständlicher, “hungriger” als die von WordPress mitgelieferte Technik ist, dafür aber effizient. Mit einer gesunden Portion Selbstdisziplin kann auf diesem Weg ein internes, pflegeleichtes und vor allen Dingen stabiles Linknetzwerk aufgebaut werden. Ohne Fleiß kein Preis.

P.S.
Übrigens verfolgt Michael Oeser in seinem How-To einen identischen Ansatz.

• Funktionsweise
• Features
• Versionsverlauf
• Installation
• Download

Funktionsweise
Das kostenlose WordPress Plugin wpTwitBox vereint in sich gängige Funktionen rund um Twitter, welche von Webverfasser kontinuierlich genutzt und eigenen Lesern zugänglich gemacht werden (Stichwort: Twit This). Bei der Programmierung der Erweiterung wurde sehr viel Wert auf die Performance der Software gelegt: WordPress-interne Cronjobs und Caching-Methoden gehören daher zum Lieferumfang. Umfangreich, jedoch mit viel Liebe zum Detail.

Selbsterklärende wpTwitBox Optionen

Features
Der Funktionsumfang von wpTwitBox zusammengefasst:

1. Automatische Aktualisierung der Followerzahl
Einmal täglich holt das prompt installierte Plugin die Gesamtzahl der Follower via Twitter API ab und aktualisiert den Counter in der Datenbank. Der passende Begriff hierfür: Caching!

Aus dem Template heraus kann auf die zwischengespeicherte Followerzahl zwecks Ausgabe wie folgt zugegriffen werden (Beispiel siehe Sidebar rechts):

<?php if (class_exists('wpTwitBox')) {
  $GLOBALS['wpTwitBox']->the_followers_count();
} ?>

Pflichtfeld für diese Option

• Twitter Nutzername

2. Twitter bei neuen Beiträgen benachrichtigen (Auto Tweet)
Nach der Aktivierung der Checkbox wird wpTwitBox versuchen, einen Tweet mit dem Titel samt Link des soeben veröffentlichen Artikels abzusetzen. Dabei spielt es keine Rolle, ob der Beitrag sofort oder zu einem späteren Zeitpunkt publiziert wurde.

Ist der Beitragstitel zu lang, so wird er vom Plugin passend gekürzt. Der Permalink zum Post wird verständlicherweise in einen kürzeren Bit.ly Link konvertiert. Es ergibt sich das Format: Blogtitel + Bit.ly URL

Pflichtfelder für diese Option

• Twitter Nutzername
• Twitter Passwort

3. Links in den Kommentaren in Bit.ly Links umwandeln
SEOs Kommentatoren jonglieren zu gerne mit Links. Nicht selten sind URLs “meterlang” und ruinieren das gesamte Layout der Kommentarspalte. Aus ästhetischen Gründen können Verweise nach dem Absenden eines Kommentars in deutlich kürzere, charmantere Bit.ly Links abgeändert werden. Denkbar wäre auch ein simpler Schutz vor Links, die im Laufe der Zeit offline gehen oder umgeleitet werden.

Kleinigkeit am Rande: Ist der umzuwandelnde Link kürzer als der resultierende Bit.ly Link, so nimmt wpTwitBox keine Konvertierung vor, da die gewünschte Länge bereits gegeben ist.

4. Permanentes Caching der Bit.ly Links
wpTwitBox ist in der Lage einen – pro Artikel eigenständigen – Twit This Link (auch ReTweet genannt) zu erzeugen und im Template mittels Funktionsaufruf auszugeben. Auch hier übernimmt Bit.ly die Herrschaft über den Link.

Ist das Caching eingeschaltet, so greift die Erweiterung auf den in der Datenbank abgelegten, also gecachten Link zu und umgeht somit ständige Anfragen an den Shortener für die Ermittlung der Kurzversion von Artikel-URLs. Genutzte Caching-Techniken sind geschwinder und eleganter als die mit der Performance verschwenderisch umgehenden Zugriffe auf externe Server. Mehr zum Thema unter Twitter-Link mit Caching-Funktion.

Im Template kann der von wpTwitBox vorbereitete Twit This Link unkompliziert eingebunden werden:

<?php if (class_exists('wpTwitBox')) { ?>
  <a href="<?php $GLOBALS['wpTwitBox']->the_tweet_link() ?>">..</a>
<?php } ?>

Funktionsaufruf gibt den (gecachten) Bit.ly Link zurück:

<?php if (class_exists('wpTwitBox')) { ?>
  <?php echo $GLOBALS['wpTwitBox']->get_tweet_link() ?>
<?php } ?>

5. Shortener J.mp anstatt von Bit.ly nutzen
J.mp ist nichts anderes als Bit.ly – gleicher Anbieter, absolut identische Daten. Der wahre Unterschied liegt lediglich an der geringeren Zeichenanzahl der Domain: J.mp ist halt 2 Buchstaben kürzer. Auf Wunsch kann J.mp also als Plugin-Shortener verwendet werden.

6. Klicks auf Bit.ly Links protokollieren
Die Optionsfelder für die Eingabe der Bit.ly Zugangsdaten sind nicht umsonst da: Sind diese richtig hinterlassen, nutzt wpTwitBox eine weitere API von Bit.ly und lässt den weltweit beliebten Shortener für diesen bestimmten Nutzer spezifische Links anlegen. Benutzergebundene Links werden automatisch zum Bestandteil der persönlichen Bit.ly History (im eingeloggten Zustand bereits auf der Bit.ly Startseite zu sehen) und geben auf Anhieb Auskunft über die Verbreitung und das Klickverhalten der angelegten Verweise.

Tipp: Einen extra Bit.ly Account anlegen, um wertvolle Statistiken separat und unabhängig von den gewöhnlichen Tweets zu erhalten.

Bit.ly History mit Links und Klicks

Generelle Hinweise

• Ab WordPress 2.7
• Plugin-Deinstallation löscht alle Optionen und den Cache
• Kostenlose Nutzung, GPL
• In Deutsch und Englisch verfügbar

Geplante Features

• Tweetbacks
• Darstellung eigener Tweets
• Validierung der Zugangsdaten
• Flexibilität des Textes im ReTweet-Link und Auto Tweet
• Vergabe der Hash-Tags

Versionsverlauf
Version 0.2 vom 21.01.2010:

• Transparentes Plugin-Icon
• Neue Funktion get_tweet_link liefert den Bit.ly Link des Artikels
• Textliche und optische Anpassungen
• Fix für Auto Tweets bei geplanten Posts

Version 0.1 vom 20.01.2010:

• wpTwitBox goes live

Installation

• Plugin downloaden
• Via FTP oder WordPress-Backend zu den Plugins hochladen
• Reiter Plugins aufrufen
• Plugin wpTwitBox aktivieren
• Einstellungen vornehmen

Download
› WordPress Plugin wpTwitBox ↓

• Format: ZIP
• Version: 0.2

Verlangsamte Ausführung durch JavaScript-Dateien
Je nach Komplexität und Funktionsvielfalt einer Website bindet der Entwickler Handvoll an externen JavaScript-Instanzen ins XHTML-Gerüst ein, um Funktionen zur Laufzeit verfügbar und ausführbar zu machen. Ein alltäglicher Prozess.

So nicht: Zuviele Requests schaden dem Ladevorgang der Seite

Ein Szenario aus dem Alltag: Zwei JavaScript-Frameworks werden geladen, plus ein jQuery-Plugin für die Slideshow, SWFObject für die Flash-Einbindung, dazu kommt noch Google Analytics oder anderes Tracking-Tool auf JavaScript-Basis.

An sich nichts, was man nicht braucht. Wenn da nicht die schmerzende Tatsache wäre, dass jede dieser Module (Modul = Datei) den Browser dazu zwingt, sich mit dem Server zu verbinden, um Daten in Form von JavaScript-Zeilen zum Rechner des Nutzers zu transferieren. Das Gewicht der Files und die Anzahl der Bytes ist an dieser Stelle nicht wirklich kritisch (was sein muss, muss sein). Vielmehr ist die Menge der Anfragen als bedenklich zu betrachten, da Browser je nach Typ eingeschränkt parallele Requests bzw. Downloads ausführen können.

Einbettung einer Gesamtdatei mit JS-Code
Je mehr Dateien von der gleichen Domain in eine Seite eingebunden werden (unabhängig vom Typ), desto länger wird im Browser die Warteschlange zum Abarbeiten, um so langsamer ist die Ausgabe. Die Erkenntnis: Idealerweise steckt der komplette JS-Code in nur einer Datei, die einmalig im XHTML referenziert wird – der Browser stellt dafür nur die einzige Verbindung her und kann nebenbei andere Medien wie z.B. Bilder herunter laden. Bringt einen Performanceschub.

Viele der erfahrenen Entwickler praktizieren diese simple Technik: In der Entwicklungsumgebung aus Gründen der Übersichtlichkeit und der Bequemlichkeit an mehreren Dateien arbeiten. Live kommt lediglich die eine Datei zum Einsatz, die aus den separaten JS-Bibliotheken gewonnen und anschließend minimiert (z.B. mithilfe des JavaScript-Compressor) wurde.

Techniken für die Bündelung der JavaScript-Sourcen
Neben dem händischen Kopiervorgang der Zusammenführung von JS-Fragmenten existieren noch weitere Methoden für das Erzeugen einer zentralen JS-Datei. Eine der bewährten Möglichkeiten ist beispielsweise ein dynamisches Load-Script in PHP, welches Dateinamen als Parameter empfängt und entsprechende JS-Files in kombinierter Form an den Browser ausgibt.

Aber auch Google Labs stellt solch zweckmäßige, installationslose Online-Lösungen öffentlich zur Verfügung, welche weiter unten samt Vorteilen praxisbezogen vorgestellt werden.

1. Google Closure Compiler
Closure Compiler ist ein kostenloser Online-Service von Google mit alleiniger Aufgabe, JavaScript-Input komprimiert zu bündeln. Warum bündeln? Das Tool fasst nicht nur die händisch eingefügten JavaScript-Fragmente zusammen, auch gängige Frameworks (jQuery und Prototype zum Beispiel) und extern abgelegte Quellen lassen sich in der Anwendungsoberfläche auswählen bzw. abrufen und fließen so ins Endergebnis mit ein. Nach diesem Prinzip wären die notwendigen Frameworks und der eigene Code in nur einer Datei vereint.

Nach der erfolgreich abgeschlossenen Kompilierung der Rohdaten steht eine Zeichenwüste zum Kopieren und Download bereit.

Pro

• Zusammenführung mehrerer JS-Dateien (eigene, externe, Frameworks)
• Komprimierung der Größe durch Bereinigung des Codes (minify)

Contra

• Entwickler übernimmt das Hosting, Caching, GZIP und CDN

Eigene JS-Inhalte und bekannte Libs mit Closure Compiler gruppieren

2. AJAX API Loader
Seit neustem verfügt Google über einen neuartigen Dienst namens Autoloader, der mehrere APIs zusammenlegt und in komprimierter Datei zurückgibt. Der Autoloader unterstützt auch GET-Parameter und so werden die zum Laden notwendige Module als URL-Aufruf übergeben, Google fast den Code der APIs in einer Datei zusammen. Der praktische Wizard hilft bei der Bündelung der APIs und der Generierung der kryptischen Adresse.

Doch die Vielfalt der möglichen Module beschränkt sich nicht unbedingt auf Google APIs: Die oben bereits erwähnten Frameworks können auf die gleiche Weise via URL-Aufruf gruppiert geholt werden – als Ergänzung eine Übersicht der auf Google verfügbaren Frameworks: Google AJAX Libraries API. Dazu werden lediglich die Namen und Versionsnummer der gewünschten Module angepasst bzw. ergänzt und als Übergabeparameter definiert. Mehr ist an dieser Stelle nicht notwendig.

In folge dessen können schwergewichtige Bibliotheken (dabei bleibt die Anzahl der Files variabel) mit nur einem Request (welcher jedoch Gold wert ist) ins eigene Projekt inkludiert werden.

Pro

• Zusammenführung mehrerer Frameworks
• Komprimierung der Größe durch Bereinigung des Codes (minify)
• GZIP-Komprimierung während der Übertragung
• Übergabe korrekter Cache-Header
• Anbindung an ein CDN

Contra

• Kein eigenes JS möglich, ausschließlich bei Google verfügbare Frameworks
• Abhängigkeit von Google

Google’s Autoloader kann APIs, aber auch Frameworks verbinden

Fazit
Aktuell berücksichtigt Google die Geschwindigkeit der Webseiten als einen nicht unerheblichen Ranking-Faktor, gibt den Entwicklern aber auch ausgereifte und kostenfreie Werkzeuge für diesen Zweck in die Hände. Die Zusammenführung der JavaScript-Dateien ist eine wichtige Schraube im mächtigen Motor der Performance-Optimierung und darf daher nicht “einrosten”.

App Engine: Die Flugzeug-Turbine steht für (Webseiten-)Turbo

Was ist ein CDN und welche Aufgabe hat es zu erledigen?
CDN steht für Content Delivery Network – ein intelligent ausgelegter Verbund aus mehreren kontinental zerstreuten Servern bzw. Server-Farmen. Die zu erfüllende Mission: Je nach geografischem Standort der Webseiten-Besucher reagiert der nächstgelegene Server auf die Browser-Anfrage und kann die angeforderten Daten prompter, also zeitsparender ausliefern als der Konkurrent auf gegenüberliegender Welthälfte. So teilen sich die Rechner im Verbund die Last und das Traffic-Aufkommen, sichern aber auch die höchste Erreichbarkeit und die niedrigste Ladezeit der dort gehosteten Webseiten oder statische Objekte. Eine “Win-Win”-Situation, sozusagen.

Ein banales Quiz zum Verständnis: Eine durchschnittliche Webseite sendet circa 20 Anfragen an den Server, um für die Darstellung notwendige Informationen zu erhalten. Wann sind die Daten schlagartiger zurück?

• A. Wenn sich der zuständige Server “um die Ecke” befindet
• B. Wenn die Anfrage um den halben Globus geht

Für größere Websites mit internationalem Publikum empfiehlt sich zweifellos ein Hosting-Provider mit angelegtem CDN (z.B. Amazon CloudFront). Dank der Ortung anhand von IP-Adressen treffen statische Files wie Bilder, CSS oder JavaScript im Browser der Kunden zügiger ein. Was bringt diese Erkenntnis wiederum für den Website- bzw. Shop-Betreiber (Produktbilder sind die besten Kandidaten)?

1. Konsumenten bedanken sich für flüchtiges Laden der Inhalte (und kaufen nachweislich mehr, denn jede Sekunde zählt).
2. Google als Suchmaschine lässt die technische Performance einzelner Pages ins Ranking einfliessen (wer braucht da noch Suchmaschinenmarketing).

Handeln ist angesagt!

Google mit eigenem Content Delivery Network
Wie bei der Einleitung oben bereits erwähnt, gehört auch Google App Engine zum kleinen, jedoch sehr feinen Kreis der Anbieter, die ihre Infrastruktur um das Content Delivery Network bereichert haben und gestellte Requests dementsprechend auch IP-bezogen verarbeiten.

Bedauerlicherweise kann Google mit keiner Anbindung an die lokal verfügbaren Server innerhalb Europa dienen (Amazon CloudFront dagegen in den USA, Europa und Asien “vertreten”), so dass beispielsweise Anfragen aus Deutschland von den in Amerika ansässigen Webservern entgegengenommen und abgearbeitet werden (einer der Server). Kleiner Wermutstropfen: Die Reaktionszeiten der ausländischen Google-Rechner sind beeindruckend geringfügig, kaum ein deutscher Hoster kann mit solch winzigen Millisekunden konkurrieren. Glück im Unglück, quasi.

Im Übrigen lässt Google eigene Applikationen ebenfalls auf den selben Maschinen hosten bzw. laufen wie die App Engine Anwendungen der Dritthersteller – Google Closure Compiler sei als Beispiel genannt. Das kann als Garant für ununterbrochene Stabilität und langfristige Zuverlässigkeit des CDN-Hosters aus Mountain View verstanden werden.

Zusätzlicher Nutzen des Hostings bei Google App Engine
Alleine wegen einem bereitgestellten CDN wäre Google’s App Engine für deutschsprachige Websites nicht interessant genug gewesen, wenn da im Zusammenhang nicht noch weitere, für Webworker recht spannende Instrumente dabei wären, welche “die Cloud” attraktiv gestalten (lassen). Fassen wir weitere Vorteile von Google App Engine ausführlich zusammen:

1. Kostenlose Nutzung des Dienstes
Jede bei Google App Engine angelegte Anwendung (in unserem Fall sind es Projekte mit statischen Inhalten) verfügt über ausreichend CPU, Bandbreite und Speicher. Fünf Millionen Aufrufe pro Monat kosten keinen Cent. Darüber hinaus wird nach CPU-Stunden oder Gigabyte-weise abgerechnet, wobei sich die jeweiligen Einheiten in Cent-Bereichen befinden (dazu die Preistabelle). Keine monatlichen Bindungsverträge et cetera.

Nutzungsstatistik auch für kostenfrei verfügbares Kontingent

2. Gesonderte, Cookie-freie (Sub)Domain
Je nach Wunsch kann das Projekt bei App Engine mit eigener Domain verknüpft werden, Anfragen an statische Daten werden z.B. auf static.domain.de umgeleitet. Verzichtet man auf die Verknüpfung der eigenen Domain mit angelegtem App Engine Project, so ist die öffentlich erreichbare Subdomain xxx.appspot.com (xxx steht dabei für den Projektnamen) das neue Zuhause der im Webseiten-Quelltext referenzierten Dateien.

Irrelevant wofür sich der Entwickler letztendlich entscheidet (eigene Domain oder doch ohne), in beiden Fällen werden beim Datenabruf – etwa die Darstellung der Bilder oder Einbindung von CSS – seitens Google keine Cookies mitgeschickt, gesetzt oder ausgelesen. Frei von jeglichen Cookies für noch weniger Bytes beim Austausch zwischen dem Server und den Clients.

Pluspunkt: Je nach Alter können diverse Browser lediglich eine begrenzte Anzahl an gleichzeitigen Anfragen pro Domain stellen. Kommt eine abweichende Domain bzw. Subdomain als eine weitere Datenquelle ins Spiel, kommt es zwangsläufig plötzlicher bei der Fertigstellung des Ladevorgangs voran.

Beide Punkte (abweichende Domain + keine Cookies) werden von Page Speed und Yahoo! YSlow als relevant eingestuft und sollen daher Beachtung finden.

Analyse-Tools bewerten die Webseiten nach mehreren Kriterien

3. GZIP-Komprimierung und Caching von Dateien
Komprimierfähige Dateien wie beispielsweise Stylesheets und JavaScript werden von Google in gestraffter Form verschickt und auf der Client-Seite (in diesem Fall ist es der Browser) entpackt. So wird Traffic gespart und die Geschwindigkeit der Datenübertragung zusätzlich gesteigert. Google App Engine erkennt solche Dateien selbsttätig und behandelt sie mit der GZIP-Komprimierung, ohne dass der Administrator des Accounts dafür aktiv werden muss (z.B. Modifizierungen am Server oder an der .htaccess).

Nach wenigen manuellen Korrekturen versieht der App Engine Server den ausgehenden Datenstrom mit korrekten Headern, die nachhaltig und effizient dafür sorgen, dass die im Browser-Cache abgelegten Elemente bis auf Wiederruf dort aufbewahrt und für die Anzeige verwendet werden sollen. Unverzügliche Darstellung im Browserfenster und ökonomische Anfragestellung zum entfernten Server ergeben sich im Endeffekt.

GZIP-komprimiert und in den Browser-Cache befördert

4. Traffic-Einsparung und Server-Schonung
Durch die Auslagerung der statischen Files auf den Google-Server kommt der eigene Server (hoffentlich) zur Ruhe und kann sich um andere Rechenaufgaben wie z.B. die Generierung von dynamischen Inhalten kümmern. Die Praxis bestätigt immer wieder aufs Neue: Nach der Ausgliederung pendelt die Serverlast spürbar zurück.

Live-Beispiel der Implementierung
Um das Hosting der Daten auf bzw. in Google App Engine und die entsprechende Integration der Quelle im XHTML-Gerüst zu demonstrieren, wurden statische Elemente (Stylesheets und Grafiken) meiner Portfolio-Website eBiene.de auf Google als eigenständiges Projekt ausgelagert. Es ging nicht um die Notwendigkeit, vielmehr um die Machbarkeit der Realisierung.

Wir verlassen an dieser Stellen den theoretischen Part des Artikels. Der praktische Teil spezifiziert, wie Objekte nach Google App Engine übertragen und in die Projektseiten eingebunden werden. Spot ab!

1. Projekt anlegen
Auf der Google App Engine Website gelangt man nach der Registrierung bzw. Anmeldung (Keine Abfrage von Konto- oder Kreditkartendaten, dafür eine kostenfreie Verifizierung per SMS notwendig) auf die Übersichtsseite der gegenwärtigen Projekte. Sind keine Projekte bis dato existent, hat man eine direkte Möglichkeit den Namen für das neue Projekt zu vergeben. Der Projektname mutiert zugleich zur Subdomain von appspot.com (ebienede.appspot.com ist in unserem Beispiel die entsprechende Subdomain). Die systemweite Eindeutigkeit des Application Identifiers hat den bitteren Nachgeschmack, das die Vielzahl der möglichen Namen von anderen Teilnehmern bereits genutzt und somit längt vergeben ist. Kreativität ist also gefragt.

Ist die Applikation erfolgreich angelegt, bekommt Developer die Gelegenheit auf das Projekt-Dashboard zu springen: In der Zusammenfassung werden Statistiken für jegliche Art an Verbrauch chronologisch abgebildet. CPU-Gesamtzeit, verstrichene Bandbreite und so weiter.

Application Identifier wird zur Subdomain des Projektes

2. Upload-Client in Betrieb nehmen
Die Nutzung des Dienstes wird durch die fehlende Möglichkeit erschwert, Daten auf die bekannte Weise via lokales FTP-Programm zum Google-Server zu übertragen. Für diesen Zweck existiert u.a. ein Entwickler-Werkzeug in Form einer smarten Anwendung, die einen vorher definierten Ordner samt Inhalt (Verzeichnisse, Files) auf den entfernten Rechner dupliziert: Ein Klick auf Deploy gleicht den Bestand der Datenstruktur ab.

Auf der offiziellen Download-Seite wird Google App Engine SDK für das gewünschte Betriebsystem heruntergeladen und installiert. Im geöffneten Tool-Fenster kann über das Menü eine New Applikation angelegt werden: Application Name ist der eben im Web gewählte Application Identifier, Application Directory ist der Ort auf der heimischen Festplatte, der als Referenz für die Spiegelung der Dateien gelten soll. Port ist 8080, andere Optionen bleiben unberührt.

Lediglich 2 Felder pro Projekt gehören ausgefüllt

3. Statische Inhalte in Google App Engine definieren
Die Applikation wird nach dem Klick auf den Button Create als entsprechender Listeneintrag im Client und auf der Festplatte im gleichnamigen Ordner angelegt. Navigiert man dahin, werden dort 3 Standard-Systemdateien vorgefunden:

• app.yaml
• index.yaml
• main.py

Im Verzeichnis werden nun Unterordner für statische Inhalte erstellt. Exemplarisch: css und img, wo jeweils Stylesheets und Bilder separiert aufbewahrt werden. Neu hinzugefügte Ordner gehören in der Konfigurationsdatei app.yaml als Ordner mit nicht dynamischem Content deklariert. Die Datei app.yaml passen wir nun händisch im Texteditor an – nach der Änderung sieht sie wie folgt aus (wobei xxx für den Projektnamen steht):

application: xxx
version: 1
runtime: python
api_version: 1

default_expiration: "365d"

handlers:
- url: /css
  static_dir: css

- url: /img
  static_dir: img

Der Parameter default_expiration kommuniziert die Tagesanzahl für das Caching, die der Server wiederum an den Browser sendet. Der Wert ist variabel.

Exemplarische Ordnerstruktur einer App Engine Application

4. Hochladen und im XHTML einbinden
Befinden sich nun Dateien in den erstellten Ordnern, so können diese via Schaltfläche Deploy auf den Server gespiegelt werden. Im zusätzlich eingeblendeten Fenster zeigt die Anwendung den Ablauf der laufenden Aktion und weist auf eventuelle Fehler hin.

Geglückter Upload sichert die Erreichbarkeit der übertragenen Dateien unter der bekannten Subdomain. Ein Test in der Adresszeile des Browsers genügt als Bestätigung. Fällt die Prüfung positiv aus, kann die Statik im Quelltext der Webseiten referenziert werden. Als Musterbeispiel sei die CSS-Datei meines Portfolios genannt: http://ebienede.appspot.com/css/global.css.

Das waren die vier Schritte, die für den Umzug vom traditionellen Hoster auf Google App Engine notwendig waren. Leider erkennt Yslow die Google App Engine Plattform nicht als vollwertigen CDN-Hoster. Das liegt an der Tatsache, dass Google im Analyse-Tool nicht als solcher hinterlegt ist. Yahoo! verrät, wie die interne Liste um weitere CDN-Provider erweitert werden kann.

Fazit
Google App Engine ist eine perfekte Alternative zum gewöhlichen Webhoster, wenn es darum geht, statische Medien sinnvoll und gewinnbringend auszulagern. Ob eine Website für diesen Zweck groß genug, die Zielgruppe ausreichend international und die angesprochene Upload-Lösung bequem ist, entscheiden ganz alleine die Projektmacher. Als kostenloser Einstieg ins Cloud Computing ist Google App Engine jedoch wärmstens zu empfehlen.

Manuell angelegtes Feld beim Verfassen eines Beitrages

Nachfolgend ist ein Einzeiler als Beispiel-Aufruf abgebildet, der das gewünschte Custom Field my_day in die Query einbezieht, aber auch danach sortieren lässt. Eine knappe, verständliche Code-Zeile mit effektivem Ergebnis.

<?php
query_posts('meta_key=my_day&meta_compare=<=&meta_value=20&orderby=meta_value');
?>

Fällt aus der Reihe: Selten genutztes Plugin

Das sind die Vorteile, die sich dadurch ergeben:

• Sinkende Ausführungszeit:
  Jedes aktive Plugin wird beim Laden der Webseite (Frontend & Backend) vom System eingescannt und in den Speicher der Applikation eingelesen. Durch die Stilllegung der einzelnen Module minimiert sich die Verarbeitungszeit der Gesamtanwendung, der interne Speicher wird für andere Aufgaben freigehalten.
• Erhöhte Sicherheit
  Im Betrieb befindliches Plugin bedeutet einen ausführbaren Code, der seinerseits angreifbar sein könnte. Bei abgeschalteten Addons schläft es sich garantiert ruhiger.

Beispiel gefällig?
WP-Crontrol stellt System-weite Cronjobs als Liste dar: Wird erst bei Bedarf aktiviert und anschließend manuell gestartet.

Fazit
Ein winziges, selbstgebautes Plugin mag zwar als Ausnahme durchgehen, die restlichen Kandidaten in der Plugin-Verwaltung sollen kritisch überprüft und je nach Notwendigkeit mit dem Status “Inaktiv” versehen werden.

Licence
Available social icons may be used in any projects, whether commercial or private nature. Please refer the ZIP archive with buttons not directly, but I would appreciate a link to this post. Thank you.

Lizenz
Angebotene Social Icons dürfen in jeglichen Projekten zum Einsatz kommen, ganz gleich ob kommerzieller oder privater Natur. Verweist bitte das ZIP-Archiv mit Buttons nicht direkt, vielmehr würde ich mich über einen Link zu diesem Beitrag sehr freuen. Herzlichen Dank.

Download
› Free Icons deutscher Social-Dienste ↓

• 4 handgezeichnete, transparente PNG Icons 32×32 Pixel
• 4 handgezeichnete, transparente PNG Icons 64×64 Pixel