Kennt ihr schon den Umbraco-Adventskalender 24 Days in Umbraco? Darin erscheint täglich der Artikel eines Community-Mitglieds rund um Themen, die mit dessen liebsten CMS zu tun haben. Auch zwei unserer Entwickler von byte5 hatten dieses Jahr die Ehre. Lukas gibt in seinem Artikel Tipps, wie ihr mit einfachen Methoden die Performance eurer Website steigern könnt. Doch lest selbst:

Lukas Schuhmacher

In diesem Artikel geht es mir nicht darum, die Performance einer Seite ans Maximum zu treiben, sondern darum, Methoden aufzuzeigen, die man on-the-fly anwenden kann ohne dass man nennenswert mehr Zeit in seine Seite stecken muss. Wenn man nach diesen Methoden arbeitet und sich daran gewöhnt hat, sollte extra Zeit für Performanceoptimierung aufzuwenden nur noch in den seltensten Fällen notwendig sein.

Caching

„Caching ist für Leute mit Performance-Problemen oder zu viel Zeit.” – Ich weiß nicht, ob jemand von euch in seiner Laufbahn zum Programmierer schon mal einen Spruch wie diesen gehört hat. Ich weiß auch nicht mehr genau, wo ich ihn gehört habe – das ist aber auch egal. Es geht um die Message des Spruchs. Und die ist – wie ihr sicher wisst – völliger Blödsinn. Caching ist essentiell wichtig, um eure Seite zu boosten und das Bestmögliche aus ihr herauszuholen. „Aber wenn die Seite doch schnell läuft?” – Schneller geht immer und Zeit kostet das Caching auch kaum.

Cached-Partials

Was lässt sich fast genauso schnell schreiben wie @Html.Partial? Richtig, @Html.CachedPartial! Wenn man sich zur Entwicklungszeit schon ein paar Gedanken macht, an welchen Stellen CachedPartials sinnvoller sind als normale Partials, kostet auch dieser Punkt fast keine Zeit. Es lassen sich hier außerdem noch weitere Einstellungen vornehmen, wie zum Beispiel cachedByPage, um einen eigenen Cache pro Seitentyp zu haben, auf der die Partials eingebunden ist, oder cachedByMember, um für die einzelnen Member zu cachen.

IHtmlString CachedPartial(
    string partialViewName,
    object model,
    int cachedSeconds,
    bool cacheByPage = false,
    bool cacheByMember = false,
    ViewDataDictionary viewData = null,
    Func<object, ViewDataDictionary, string> contextualKeyBuilder = null)

Während der Entwicklungszeit kommen euch die Cached-Partials übrigens nicht in die Quere, da sie nur cachen, wenn der Debug-Modus auf „false“ steht. Man sollte zudem im Hinterkopf behalten, dass der Cache der Partials durch Umbraco publish events geleert wird.

WebApi.OutputCache

Wie oft machen wir Abfragen an WebApis, bei denen wir wissen, dass immer dieselben Daten zurückkommen werden? Zum Beispiel, wenn wir über eine WebApi Einstellungen aus dem Backend ziehen. Warum sollte man hier immer länger auf eine Antwort warten als notwendig, vor allem wenn der WebApi.OutputCache in einer Zeile funktioniert? Bei WebApi.OutputCache.V2 handelt es sich um ein Nuget-Package. Nach der Installation kann man einfach seinen Methoden ein Attribut hinzufügen und sie so cachen. Hier ein Beispiel für die Anwendung:

publicclassMyController : UmbracoApiController
{
    [WebApi.OutputCache.V2.CacheOutput(ClientTimeSpan = 60, ServerTimeSpan = 60)]
    public string cachedFunction(string parameter)
    {
        // do something


        return something;
    }
}

Folgende Properties stehen zur Verfügung:

  • ClientTimeSpan (entspricht dem CacheControl MaxAge HTTP-Header)
  • MustRevalidate (entspricht dem MustRevalidate HTTP-Header)
  • ExcludeQueryStringFromCacheKey (Query-Strings werden beim Cachen ignoriert)
  • ServerTimeSpan (Cache-Period auf der Serverseite)
  • AnonymousOnly (Cache ist nur für Anfragen aktiviert, wenn Thread.CurrentPrincipal nicht definiert ist)

Es gibt ein paar praktische Variationen des Output-Caches:

CacheOutputUntil, CacheOutputUntilToday, CacheOutputUntilThisMonth und CacheOutputUntilThisYear. Diese dienen dazu, einen genauen Zeitpunkt festzulegen bis wann gecached werden soll.

LeBlender

LeBlender ist eine kostenlose Backend-Erweiterung. Es lassen sich damit komplexe Grid-Editoren mit Leichtigkeit erstellen. Ich könnte mir das Arbeiten ohne gar nicht mehr vorstellen.

Erstellt einfach einen neuen Grid-Editor in der Developer-Section wie gewohnt. Wählt als Grid-Editor den LeBlender-Editor aus:

Leblender1

Jetzt können wir einfach Properties hinzufügen. Hier können wir auch unsere eigenen Datatypes verwenden.

LeBlender besitzt einen eingebauten Cache. Wir müssen hier nur die Cache-Period eintragen et voilà. Wenn man hier bei allen Editoren die Cache-Period sinnig setzt, hat man schon einiges gewonnen für die Performance der Seite.

Leblender2Leblender3

Wer LeBlender noch nicht kennt, sollte sich dazu unbedingt mal einlesen.

Weitere Vorteile von Caching

Das Wichtigste – egal, bei welcher Art von Caching – ist für mich, sich vor oder spätestens während der Entwicklung Gedanken darüber zu machen, wie oft sich Daten tatsächlich ändern und wie wichtig es ist, immer die aktuellen Daten zu haben. „Macht es wirklich einen Unterschied, ob meine neuen Daten sofort oder erst in zwei Stunden aktualisiert werden?“ – Wenn die Antwort auf diese Frage „nein“ ist, sollte unbedingt gecached werden. Konsequentes Caching bietet auch weitere Vorteile, teils mit enormen Auswirkungen.

Einige von euch werden sicherlich mit Drittsystemen arbeiten, die euren Kunden pro Call Geld kosten. Wenn man das Ergebnis des Calls cached, kann schnell aus tausenden Aufrufen einer werden. Der Kunde wird sich freuen.

Ein anderer Vorteil ist die Arbeitsweise generell. Wenn man sich frühzeitig Gedanken über den Datenfluss in seinem System macht, verhindert man Fehler, die je später sie auffallen größere Auswirkungen haben. Eure Teamleiter werden es euch danken.

„Schnellere Ladezeiten hin oder her, wenn der Nutzer nicht ewig laden muss, macht das doch auch nichts, schließlich merkt man hundert Millisekunden ja nicht wirklich, oder?“ – Der Nutzer vielleicht nicht, Suchmaschinen allerdings schon! Das Caching wirkt sich auch auf die Geschwindigkeit des Indexierens einer Seite aus, was zu einem besseren Ranking verhelfen kann.

Typed-Content

Man sollte darauf achten, immer Typed-Content zu verwenden. Typed-Content ist generell performanter als Dynamics und dazu weniger fehleranfällig. Wenn man noch mit Dynamics arbeitet, sollte man langsam umsteigen, denn es ist geplant, ab Umbraco Version 8 den Support für Dynamics für den Zugriff auf IPublishedContent einzustellen.

Common-Pitfalls & Anti-Patterns

Wenn ihr neu bei Umbraco seid, gibt es eine Handvoll Regeln, die ihr einhalten solltet, um unerwünschte Fehler zu vermeiden. Auf our.umbraco gibt es zu diesem Thema einen Artikel, auf den ich am Schluss noch hinweisen möchte.

 

Dieser Artikel erschien am 20. Dezember 2017 in englischer Übersetzung auf 24 Days in Umbraco.

 

Zurück