Das Thema Customer Experience (CX) rückt immer weiter ins E-Mail-Marketing hervor. Vielen Versendern wird, dass sich jenseits ihres Wahrnehmungshorizonts regelmäßig Kunden über schlechte E-Mails ärgern, ohne sich zu beschweren.
Vor allem die Ladezeit ist ein unterschätztes Thema. Dauert der Aufbau eines Newsletters zu lange, generiert dieser weniger Klicks. Und gerade, wenn tausenden Empfänger eines Newsletters gleichzeitig eine Website aufrufen wollen, haben Webserver mächtig zu kämpfen.
Aber warum findet das Thema Newsletter-Ladezeit so wenig Beachtung? Das hat vor allem zwei Gründe: Es ist schwer, die Ladezeit unter realen Bedingungen zu testen. Am eigenen Büro-PC sind Probleme oft gar nicht ersichtlich. Erst beim Versand, wenn tausende User gleichzeitig auf eine E-Mail zugreifen, werden Server in die Knie gezwungen.
Ein zweiter Grund: Als Versender hat man relativ wenig Einfluss auf schnelle Ladezeiten. Das Hosting von Grafiken übernimmt häufig der ESP (Email Service Provider). Vor allem dann, wenn die Domain für Absender und URLs alle „aligned“ sind.
Darum sind langsame Newsletter problematisch.
E-Mails mit langer Ladezeit haben führen zu drei Problemen.
- Geringere Konversionsraten
Nicht nur im E-Commerce führen langsame Lade- und Reaktionszeiten zu verärgerten Usern. Das beginnt mit dem initialen Aufruf der E-Mail. Dauert der Aufbau zu lange, brechen die User den Vorgang ab. - Negative Reputation
Eine schlechte User Exerience führt dazu, dass User einen Absender oder eine Marke zukünftig meiden. Vor allem, wenn Probleme wiederholt auftreten. Es ist dann sehr schwierig, diese wieder für sich zu begeistern. - Schlechte Zustellbarkeit
Geringe Klickraten und hohe Beschwerderaten sind ein Indikator für Spam. Dienste wie Gmail oder Yahoo Mail merken sich das und legen E-Mails von dem Absender bzw. mit der IP-Nummer häufiger im Spamordner ab.
Wie bemisst sich E-Mail-Geschwindigkeit?
Wann ist eine Website “schnell”? Es gibt hier eine ganze Reihe an Metriken, welche die Performance einer Website beschreiben.
Full-email load time
Die E-Mail-Ladezeit (Email load time) drückt aus, innerhalb welcher Zeit eine Seite komplett geladen ist. Also die Dauer, bis man mit ihr umfänglich interagieren kann. Faustregel: Die Full-email load time sollte nie 3 Sekunden überschreiten.
Time To First Byte (TTFB)
Eine weitere Metrik ist die Zeit bis zum ersten Byte. TTFB misst die Dauer von der HTTP-Anforderung des Benutzers oder Clients bis zum ersten Datenpaket der Seite, die vom Browser empfangen wird.
Die Zeit bis zum ersten Byte umfasst drei Teile:
- Die Zeit zum Senden des Requests an den Server.
- Zeit für die Bearbeitung des Requests.
- Zeit zum Senden des ersten Bytes als Antwort auf den Request
DNS Lookup Time
Die DNS Lookup Time spielt eine Rolle, wenn ein E-Mail-Newsletter Ressourcen (z. B. Bilder oder Fonts) von verschiedenen Hosts (mit jeweils eigener Domain bzw. Subdomain) abruft. Denn für jede muss zunächst mal die IP-Adresse ermittelt werden. Dazu dient der DNS des Internet Service Providers, welchen der User nutzt. Als Newsletter-Versender kann man hier also wenig optimieren. Außer natürlich die Anzahl verwendeter Domains auf ein Minimum zu reduzieren. (Das macht im Hinblick auf DMARC eh Sinn.)
Time to start render
“Time to start render” ist jene Zeitspanne, ab der im Email Client etwas sichtbar wird. Zum Beispiel ein Hintergrund erscheint. Rein psychologisch hat dieser Moment eine große Bedeutung. Denn der User spürt, dass etwas passiert.
Time to interaction
Auch wenn ein Newsletter noch nicht komplett geladen ist (siehe Seiten-Ladezeit), kann man mit ihr manchmal schon interagieren. Also scrollen, navigieren oder ein Formular ausfüllen. Die Spanne bis zu diesem Zeitpunkt wird “Time to interaction” genannt.
Wie lässt sich ein schneller Newsletter aufsetzen?
Nachfolgend erfahren Sie, wie ein “Speed-first-Ansatz” beim Aufbau einer Website umgesetzt werden kann.
Schritt 1: Ein sauberes HTML-Template aufsetzen
Einen großen Einfluss auf die Website-Geschwindigkeit hat die E-Mail selbst.
Schnelle Ladezeiten lassen sich am besten erreichen, wenn auf Folgendes weitgehend verzichtet wird:
- Verschachtelte Tabellen
- Animationen (GIFs)
- Dateianhänge
- Großflächige Grafiken
- Eingebettete Videos
- Externe Verweise auf CSS, und Fonts
Das Problem: Je nach ESP wird Code für alle irgendwo verwendeten Features mitgeschickt. Selbst dann, wenn diese auf der Seite gar nicht zum Einsatz kommen.
Die Summe aller zu landenden Ressourcen (Quellcode, Grafiken etc.) E-Mail sollte nicht mehr als 300 KB groß sein. Der Quellcode selbst (HTML und CSS) nicht mehr als 80 KB. Schon allein deshalb, weil Gmail E-Mails abschneidet, wenn sie mehr als 102 KB beanspruchen.
Schritt 2: Einen professionellen ESP auswählen
Ok, natürlich spielen bei der ESP-Auswahl viele Kriterien eine große Rolle. Und tatsächlich ist der Einfluss des Providers auf die E-Mail-Geschwindigkeit eher mäßig. Dennoch gibt es ein paar Punkte, die bei der Auswahl beachtet werden sollten.
- Es ist ratsam, bei Marketing Clouds und ESPs auf Freiheiten bei der Konfiguration und des Hostings zu achten. Steht zum Beispiel ein professionelles Content Delivery Network (CDN) oder ein Cache zur Verfügung.
- Hilfreich sind Features, wie die Anzeige des Datenvolumens oder eine automatische Grafikoptimierung. Auch die Möglichkeit einer Pausierung bzw. Drosselung der Versandgeschwindigkeit kann nützlich sein, wenn z. B. ein Online-Shop in die Knie geht.
- Vor allem preisgünstige ESPs liefern E-Mail-Templates, auf deren Quellcode man wenig Einfluss hat. Hier entscheidet am Ende immer die Qualität des generierten HTML – siehe Punkt 1
Achtung: Die Email Design Tools vieler ESP erstellen nicht immer automatisch Thumbnails. Vor allem dann nicht, wenn die Grafiken auf einem anderen Server liegen und Sie zum Einfügen lediglich die URI eingeben.
Ergänzende Artikel
Fazit
