Schriftzug Cache auf futuristischem grünen Hintergrund

WordPress und die Krux mit dem Cache

Unserer Webseiten werden immer komplexer und grösser. Mehr Bilder, mehr Animationen und mehr Funktionen. Microsoft, Google und andere bauen bereits komplexe Webapplikationen wie z.B. ein Office als „Webseite“. Damit Webseiten überhaupt noch schnell abrufbar sind ist ein vernünftiges Caching unumgänglich.

Okay cool! Aber was genau ist ein Cache und wie funktioniert er?

Wenn man im Webbereich von „Cache“ spricht ist nicht immer klar was damit gemeint ist. Ziemlich traditionell gibt es den Browser Cache. Dein Browser (Chrome, Firefox oder Internet Explorer) speichert bei einem Aufruf einer Webseite standardmässig viele Dateien auf deinem Computer oder Smartphone.

Es werden zum Beispiel die Bilder, die auf der Webseite angezeigt werden gespeichert. Falls du die Seite zu einem späteren Zeitpunkt erneut aufrufst müssen diese Dateien nicht erneut heruntergeladen werden, sie werden stattdessen direkt von deinem Speicher geladen. Dieses Verhalten führt dazu, dass eine Webseite schneller in deinem Browser geladen und dargestellt wird.

In meinem Beitrag geht es aber um einen anderen Cache. Ich spreche von einem serverseitigen Cache.

Hmm okay! Und was ist das jetzt?

Ein Serverseitiger Cache ist ziemlich einfach erklärt. Wenn du z.B. die Seite von diesem Blogartikel aufrufst müssen auf dem Server viele Berechnungen durchgeführt werden. Der Titel, Text und weitere Daten müssen aus der Datenbank geladen werden. Alle diese Informationen müssen in ein grosses HTML Dokument eingepflegt werden.

Danach wird dieses HTML Datei deinem Browser gesendet – und der Browser zeigt die Webseite an. Das Ergebnis kann übrigens jede Person ansehen, wenn du dir den Seitenquelltext dieser Webseite betrachtest. Je nach Komplexität der Webseite und Anzahl der Berechnungen die notwendig sind um das HTML Dokument zu erstellen kann ziemlich viel Zeit vergehen.

Langsame Webseiten mag niemand von uns. Warten ist scheisse! Da sich die Seite von diesem Blogartikel in Zukunft kaum verändert, ist es sinn frei die bei jedem Aufruf immer komplett neu zu berechnen. Und hier kommt die Idee eines Serverseitigen Caches zum Einsatz.

Falls die Seite schon einmal berechnet wurde, kann man die erstellte HTML Datei abspeichern. Fall die Seite erneut abgefragt wird, kann man direkt diese Datei ausliefern. Damit entfällt der Schritt der Berechnungen und eine Webseite ist sehr viel schneller geladen.

Auch der Blog hier verwendet einen Serverseitigen Cache, ich habe das Rad dabei nicht neu erfunden, sondern nutze ein kleines Plugin (Cachify), dass das Management des Caches für mich übernimmt.

Wo ist jetzt die Krux?

Die Krux liegt an meinem Design. Immer unterhalb eines Artikels zeige ich die Anzahl „Views“ an. Mit aktiviertem serverseitigem Cache gibt es aber zwei gravierende Probleme.

Das erste Problem ist, dass die Anzahl der Views wird beim Aufruf des Artikels nicht mehr aktualisiert wird. Da die Berechnungen übersprungen werden wird die Anzahl nicht mehr aktualisiert.

Das zweite Problem – es wird immer eine falsche View Anzahl dargestellt. Selbst wenn die Anzahl korrekt gezählt werden würde, wird die aktuelle Zahl nicht mehr vom Server geladen, sondern eine veraltete Zahl direkt aus dem Cache ausgegeben.

Oh das ist aber schade – und was nun?

Das Problem kann man ziemlich einfach umgehen in den man den Serverseitigen Cache wieder deaktiviert. Aber das will ich nicht. Deswegen suche ich einen anderen Lösungsansatz.

Die Lösung heisst Ajax – und Nein damit ist nicht das Putzmittel gemeint. Ajax ist eine Technologie, die zur Datenübertragung zwischen Browser und Server dient. Kurz und einfach: Wenn die Seite im Browser im geladen wurde, kann der Browser eine Anfrage an den Server stellen. Genau diese Funktion können wir für unser Problem nutzen – Wenn die Seite geladen ist, fragt der Browser per Ajax auf dem Server die Anzahl Views ab und trägt diese Zahl an den richtigen Ort ein.

Mit derselben Möglichkeit können wir dem Server mitteilen, dass jemand den Artikel ansieht und die View Anzahl aktualisiert werden muss.

Ajax und WordPress – eine Symbiose

Ajax innerhalb von WordPress einzusetzen ist einfach nachfolgend zeige ich hier meine Vorgehensweise, die sich über die Jahre bewährt hat.

Vorbereitung

Als erstes müssen wir definieren wo unsere Zahl steht. Bei mir sieht das folgendermassen aus:

<span class="viewtxt" data-postid="'.get_the_ID().'"></span>

In diesem Codebereich wird mein View geladen. Wichtig ist für mich die Klasse „viewtxt“. Anhand der Klasse weiss nachher der Browser wo die Zahl der Views angezeigt werden soll. Zusätzlich habe ich noch ein „data-postid“ hinzugefügt. Hier wird die ID des aktuellen Beitrags geladen.

Danach brauchen wir in der functions.php des aktuellen WordPress Theme eine PHP Funktion die die aktuelle View Anzahl aus der Datenbank lädt.

function rme_get_view_per_post_ajax() {
    $post_id = esc_attr( $_POST['post_id'] );
    the_field('views', $post_id);
    exit;
}
add_action( 'wp_ajax_rme_get_view_per_post_ajax', 'rme_get_view_per_post_ajax' );
add_action( 'wp_ajax_nopriv_rme_get_view_per_post_ajax', 'rme_get_view_per_post_ajax' );

Wichtig ist es eine Ajax Funktion immer mit „exit;“ zu beenden.

Nun kommt der wichtigste Teil wir erstellen eine neue javascript Datei z.B. view.js – In dieser Datei wird der Ajax Abruf gemacht.

//Views pro Artikel laden und anzeigen (Echtzeitdaten trotz Caching) Ajax Call
$('.viewtxt').each(function() {
    var post_id = $(this).data('postid');
    var insert_in = $(this);
    $.ajax({
        type: 'post',
        url: ajax_var.url,
        data: 'action=rme_get_view_per_post_ajax&post_id='+post_id+'',
        success: function(response){
            //Wert eintragen
            insert_in.text(response);
        }
    });
});

Nun muss die Javascript Datei im Theme noch geladen werden. Dies steuern wir wieder über die functions.php

function rme_ajaxload_scripts() {
    wp_register_script( "ajax-view-script",  "Pafadzur/view.js", array('jquery'), false, true );
    wp_enqueue_script( 'ajax-view-script' );
    wp_localize_script( 'ajax-view-script', 'ajax_var', array('url' => admin_url('admin-ajax.php')) );
}

Zur Erklärung:

Erst registrieren wir das Script in WordPress, danach geben wir es aus. Mit der „localize“ Funktion können wir noch eine Variabel an das Script übergeben – in unserem fall ist das die URL zum WordPress Ajax Script.

Nun haben wir immer eine aktuelle View Anzahl in der Ausgabe, nun müssen wir ebenfalls per Ajax die View Anzahl beim Seitenaufruf noch aktualisieren.

Dazu verwenden wir diese PHP Funktion die wieder in die functions.php kommt:

function rme_update_view_per_post_ajax() {
    $post_id = esc_attr( $_POST['post_id'] );
    $views = (int) get_field('views', $post_id);
    $views++;
    update_field('views', $views, $post_id);
    exit;
}
add_action( 'wp_ajax_rme_update_view_per_post_ajax', 'rme_update_view_per_post_ajax' );
add_action( 'wp_ajax_nopriv_rme_update_view_per_post_ajax', 'rme_update_view_per_post_ajax' );

Und folgende Javascript Funktion:

//Views aktualisieren bei Seitenaufruf
if($('body').hasClass('single-post')) {
    var post_id = $('.viewtxt').data('postid');
    $.ajax({
        type: 'post',
        url: ajax_var.url,
        data: 'action=rme_update_view_per_post_ajax&post_id='+post_id+''
    });
}

Das Caching von Seiten bringt definitiv viele Vorteile aber auch immer wieder kleine Hürden. Aber mit etwas kreativem denken, kann man diese Hürden problemlos umgehen ohne das man aufs Caching verzichten muss.

Wie sicher ist WordPress? Teil 1
Speed! Speed! Speed! - Ich bin jetzt auf AMP!

Noch keine Kommentare

Schreiben Sie einen Kommentar

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Interessantes

Über mich

Bild von Samuel Rüegger

Samuel Rüegger

Mein Name ist Samuel, ich arbeite als Webentwickler und blogge über alles was mir gerade durch den Kopf geht… 😉

Social Media

Webhosting: cyon

Werbebild vom Webhoster Cyon

Kontaktiere mich

Populäre Beiträge

Instagram

Newsletter