Was macht gemeinhin einen Zauber aus? Die Illusion. Eine Illusion findet statt, wenn man etwas anderes wahrnimmt als das, was geschieht. Oder auch, wenn man dies gar nicht wahrnimmt. Wie im Fall einer Webseite, die in weniger als 100 Millisekunden lädt. Wieso 100 Millisekunden? Das ist die Frequenz, in der das Auge Signale zum Okzipitallappen im Gehirn weiterleitet. Alles, was schneller stattfindet, wird als sofort respektive ununterbrochen wahrgenommen. Im starken Gegensatz dazu stehen Webseiten mit mehreren Sekunden Ladezeit. Hier entstehen beim Seitenbesucher weniger Entzückung und Verzauberung, sondern eher das Gefühl, ignoriert zu werden, ja Verlassenheit. Und nicht selten wird dann eben die Webseite verlassen.

Das Alles entscheidet sich rasch und unterbewusst. Ein weiterer wichtiger Aspekt ist die Konstanz der Ladezeit. Eine langsame Abfrage ist gut, solange sie immer langsam ist; also, wenn man schon weiß, dass man sich nach dem Klick auf den Button einen Kaffee holen gehen kann, wird man weniger nervös, als wenn eine üblicherweise zügige Aktion unerwartet lange dauert. Damit können wir aus Benutzersicht die ideale Ladezeit einer Webseite definieren: immer unter 100 Millisekunden. Jetzt müssen wir nur noch eins und eins und maschinelles Lernen zusammenzählen und können daraus schließen, dass bei Google eben solche Seiten besser gelistet werden.

Grundsätzlich ist das, was einen Benutzer stört, schädlich für eine gute Platzierung – wie beispielsweise eine lange Ladezeit. Auch wenn der Eindruck entsteht, dass viel geladen wird und womöglich so einiges, was man gar nicht möchte. Auf einen Link wird mit einer gewissen Erwartungshaltung geklickt, meist möchte man anschließend ein Bild sehen und etwas Text lesen. Wenn dann aber die Ladezeit kein Ende findet, fragt man sich schon, was eigentlich passiert. Wenn es um weniger als Zehntelsekunden geht, sind wir bei der Formel 1 – und da schicken wir keine S-Klasse an den Start. Allrounder wie WordPress und Magento mit vielen Modulen tun sich hier naturgemäß schwer. Caching-Plug-ins und -Erweiterungen für solche Systeme sind per se dadurch limitiert, dass sie sich eingliedern müssen. Bis diese nämlich dran sind und endlich „schnell sein dürfen“ ist die Zehntelsekunde schon vergangen.

Eine Idee ist es, die erste aufgerufene Seite index.php einer derartigen Software für einen zügigeren „first bite“ anzupassen. Damit beschleunigt sich die Auslieferung auf den geforderten Wert, ohne dass der Scope des Systems verlassen wird. Dynamische Inhalte werden in einem solchem Szenario über Frontend-Microservices bedient, man könnte es auch als asynchrones Hole Punching bezeichnen. Gemeint ist, dass die Webseite blitzschnell statisch geliefert wird und dann – falls notwendig – benutzerspezifische Inhalte wie beispielsweise der Miniwarenkorb oder die Anzeige der Anzahl neuer Nachrichten nachträglich per JavaScript ersetzt werden. Google „versteht“ seit Ende November 2015 solche Webseiten, vorher wäre das Bereitstellen einer zusätzlichen, suchmaschinenfreundlichen Version notwendig gewesen.

Es ist prima, wenn der Server in unter zehn Millisekunden reagiert; muss er aber mit einer riesigen Menge an HTML-, CSS- und JavaScript-Dateien antworten, verhindern wir dann doch wieder das möglicherweise verzaubernde Erlebnis Webseitenbesuch. Wer bereits das von einem Grafikdesigner erstellte Layout in Form eines Mock-ups (Vorführmodell) vorliegen hatte, der hat sich möglicherweise auch schon einmal gefragt, weshalb er sich eigentlich so sehr in Geduld üben muss, bis dieses Layout in einer Webseite sichtbar sein wird. Nach dem gleichen Prinzip wie manch einer eine Individualsoftware in Auftrag gibt, mit der Anmerkung, dass sich das prinzipiell auch in Excel machen lässt und daher nicht lange dauern kann, lässt sich behaupten: Das Bild des Designers kann man nehmen und direkt in die Webseite stecken. Statt hundert Dateien nur zwei. Das Frontend ist tot.

Realistische Nutzerszenarien

Allerdings sollte man sich davor hüten, zum IMG-Tag zu greifen; eine Area Map müsste für jede Viewport-Größe neu berechnet werden. Stattdessen nutzt man besser eine HTML-Datei mit einer Area Map und einem SVG-Objekt (Listing 1).

<html lang=en>
<head>
  <meta charset=utf-8>
  <meta content="width=device-width,initial-scale=1"name=viewport>
  <style>*{margin:0}.modal{display:none;position:fixed;z-index:1;left:0;top:0;width:100%;height:100%;overflow:auto;background-color:#000;background-color:rgba(0,0,0,.4)}</style></head>
<body>
<figure id=imagemap>
  <svg viewBox="0 0 1739 15591">
    <defs>
      <style>.menu-link{cursor:pointer;outline:0}img[src$=".svg"]{width:100%}</style>
    </defs>

    <image height=15591 width=1739 xlink:href=php10.jpg>
    </image>

    <a xlink:href=#beyond>
      <rect height=15 opacity=0 width=122 x=765 y=56 class=menu-link></rect>
    </a>
    <a xlink:href=#trusted>
      <rect height=15 opacity=0 width=102 x=890 y=56 class=menu-link></rect>
    </a>
    <a xlink:href=#resources>
      <rect height=15 opacity=0 width=70 x=996 y=56 class=menu-link></rect>
    </a>

Hyperlinks, Hamburger-Navigation für Smartphones, Formulare (Listing 2), all das geht auch hier. Vielleicht sollte man die Gelegenheit nutzen (und nicht ganze Bibliotheken), und selektiv nur das, was benötigt wird, hinzufügen.

<foreignObject height=530 width=600 x=1004 y=14058>
  <div xmlns=http://www.w3.org/1999/xhtml>
    <form id=contactForm onSubmit="return false;">
      <input id=subject name=subject class=input placeholder=subject required>
      <input id=name name=name class=input placeholder="full name"required>
      <input id=contact_number name=contact_number class=input placeholder="contact number">
      <input id=email_address name=email_address class=input placeholder="email address"required>
      <textarea id=message name=message required style=height:220px;width:492px;border:none;color:#62615d;background-color:#f6f6ef;margin-top:11px;margin-left:6px;margin-bottom:4px;max-height:200px></textarea>
    </form>
  </div>
</foreignObject>

Es lebe das Frontend!
Unterschiede beim Ausreizen des SVG-Objekts offenbaren sich erst bei der Einbettung von Videos; gelingt dies im Chrome einwandfrei, haben beispielsweise Firefox und Safari derzeit noch ein Problem. Der Formel-1-Wagen nimmt Form an. Für die Serienfertigung benutzen wir etwas PHP (Listing 3).

<body>
<?php
$correctY = 0;
$correctBox = 0;

$defaultImg = '/img/' . strtoupper(str_replace(".php","",basename($_SERVER['SCRIPT_NAME']))) . '.jpg';
if (file_exists(BASE_PATH .'/public_html' . $defaultImg)) {
  list($frontendWidth, $frontendHeight) = getimagesize(BASE_PATH .'/public_html' . $defaultImg);
  if ($frontendHeight !== 3216) {
    $correctY = $frontendHeight - 3216;
    $correctBox = 3;
  }
  $frontendImg = $defaultImg;
}
?>
<figure id=imagemap>
  <svg viewBox="0 0 <?php echo $frontendWidth?> <?php echo 3216+$correctY-$correctBox?>">

    <image height=<?php echo 3216+$correctY-$correctBox?> width=<?php echo $frontendWidth?> xlink:href=<?php echo $frontendImg?>>
    </image>
<!-- ... -->
<!-- Footer Link: -->
    <a xlink:href=/imprint.php>
      <rect height=33 opacity=0 width=100 x=80 y=<?php echo 3108+$correctY?> class=menu-link></rect>
    </a>

Sofern das Bild mit dem entsprechenden Namen vorliegt, enthält die eigentlich aufgerufene Datei, z. B. imprint.php lediglich eine Zeile:

<?php require 'magic.php';

Mit diesem Ding können wir aus der Boxengasse brausen, hinter dem Steuer sitzt Kimi Räikkönen (ein finnischer Formel-1-Fahrer) und nicht etwa ein hineingezwängter Sumo-Ringer – doch was ist das für ein Geklapper? Sind wir etwa auf einer Hochzeit? Da hat uns doch jemand klammheimlich jede Menge Blechdosen ans Auto gebunden! (Abb. 1)

Verflixt, diese kleinen Codeelemente. Was machen die eigentlich? Der Sinn erschließt sich uns Performancefreaks kaum. Wie ein Paketkurier liefern wir einfach aus, vierzig oder mehr auf einer Seite sind keine Seltenheit. Retouren gibt es selten: Die Anfrage, Pixel herauszunehmen, bearbeiten wir selten. Eines ist bei dem Analysevoodoo klar: Es gilt die Heisenberg’sche Unbestimmtheitsrelation – Beobachtung beeinflusst Wirklichkeit, die Messung selbst ändert das Ergebnis. Ein Tool, das die Performance einer Webseite bewertet, ist Google Pagespeed Insights.

Oft ist es nur ein kleines zusätzliches, von extern nachgeladenes und nicht größenoptimiertes Tracking-Bildchen, das die Performancebewertung stört. Ob Google die Kriterien auch exakt so in sein Ranking einfließen lässt, sei dahingestellt, aber durch Entfernen oder zumindest Optimieren einer solchen Datei lässt sich unter Umständen bereits die Bewertung um eine Kategorie erhöhen. Aber oft kommen gerade diese Elemente von einem anderen Server, selbst über Google gezogene Schriftarten und das Google-Analytics-Element gehören dazu. Diese Tatsache sollte nicht zu dem Trugschluss verleiten, die hauseigenen Elemente würde der Suchmaschinenprimus nicht auch negativ in die Bewertung einfließen lassen.

Das Bild des Designers hat nicht nur CSS, sondern auch die seltenen, speziellen Schriftarten bereits integriert und so landen wir mit unserem Ansatz in der Performancebewertung ganz oben (Abb. 2).

Indiz für ökonomisches Potenzial

Vielleicht liegt es an der gestiegenen Anzahl mobiler Teilnehmer: Es deutet so manches darauf hin, dass Geschwindigkeit ein großer, ja möglicherweise entscheidender Faktor für das Ranking bei Google ist. Interessant ist in diesem Zusammenhang ein Vergleich von zwei Seiten derselben Domain: www.infinitehooks.com.

Sind die meisten Unterseiten mit dem beschriebenen Frontend-Duo-Ansatz für magische Geschwindigkeit ohne jeglichen Text im Body gebaut, ist die Landingpage selbst normal erstellt worden. Wegen des experimentellen Charakters und Hinweisen, dass Google beim Indizieren von Bildern nicht seine Texterkennung einsetzt, erschien dies als zu riskant, um nicht zu sagen, als SEO-Suizid. Doch selbst SEO-Experten waren überrascht vom Ergebnis: Nicht nur, dass die Seite www.infinitehooks.com/c/platforms.php mit lediglich einem SVG-Objekt sehr wohl von Google auf der ersten Seite gelistet wurde, sie erschien dort – wenn man lediglich nach dem Produktnamen suchte – sogar vor der Homepage, und das ist ungewöhnlich (Abb. 3).

Die HTML-Seite mit Meta-Keywords, Metabeschreibung und einem Bild ist on-site SEO pur. Es wurden keine suchmaschinenfreundlichen, semantischen Überschriften oder CSS-Klassen verwendet, genauer gesagt gibt es überhaupt keine Überschriften; die Seite ist schlank und ohne Schnickschnack. Nach dem Frontend-Frühjahrsputz, die Seitengeschwindigkeit im Auge behaltend und vergleichsweise flott, gönnen wir uns dann zum Beispiel schon mal einen Image Slider, mehr Responsiveness, ein Video (das nach Klick auf einen Platzhalter eingebunden wird) und was einem sonst noch gefällt. Ist die Diät gar für einen großen Webshop mit vielen Millionen Euro Umsatz geeignet? Wer sich mit der Konkurrenz messen will, kann das mit einigen Produkten, mit denen er aktuell auf Seite drei oder vier bei Google liegt, ausprobieren und die Umsatzentwicklung beobachten.

Für eine Produktdetailseite lässt sich die Technik der Reduzierung bestimmt am besten einsetzen. Denn was will der Kunde hier schon sehen außer einem Titel, ein wenig Beschreibung und einem Bild? Mit diesen Ansätzen erhielten wir bei unterschiedlichen Speedbewertungstools die volle Punktzahl. Google ändert allerdings 500 Mal pro Jahr seine Algorithmen; auch das Page-Speed-Tool wurde aktualisiert und erwartet inzwischen beispielsweise die noch stärker optimierten Bildformate JPEG 2000, JPEG XR und WebP. Um seitdem konstant die volle Performancepunktzahl zu erhalten, müsste weiter optimiert werden.