Vor kurzem sendete mir Netlify, der bisher kostenlose Hoster meiner Seite Sustaphones zum Finden nachhaltigerer Telefone, diese Warnung:
[Netlify] You’ve reached 50% of your current bandwidth allowance on onli's team
You’ll need an allowance increase soon!
Your bandwidth usage on your team (onli's team) has reached 50% of the current allowance in your billing cycle from July 29 to August 29.
If bandwidth usage goes over the allowance before the end of the billing cycle, we’ll add an extra bandwidth pack for $55, increasing your allowance by 100GB for the current billing cycle.
Alternatively, you can increase your bandwidth allowance to 1TB/month by upgrading to Pro, which is free for the first month if it’s your first time on Pro. Visit the pricing page to compare plans.
Zwei große Überraschungen: Wie kann eine Webseite, die aus einer einzelnen HTML-Seite besteht und laut Googleauswertung nur mittelmäßig oft gefunden wird, so viel Traffic generieren? Das kostenlose Kontigent sind immerhin 100 GB. Und warum kosten weitere 100 GB ganze 55 USD?
Auf beide Fragen fand ich keine klaren Antworten (dazu unten mehr), aber ich nahm die Email zum Anlass den beim Hoster landenden Traffic massiv zu reduzieren. Knapp dokumentiert im zugehörigen Issue, beschreibe ich im folgenden meine umgesetzten und erwogenen Maßnahmen ausführlicher.
Seitenverschlankung
Sustaphones wurde von mir als statisch generierte Seite umgesetzt. Eine Sammlung von Rubyprogrammen, alle zu finden auf Gitlab, erstellen die einzelne HTML-Seite. Da diese schon einige Telefone umfasst – die Datenbankdatei kennt sogar 612 Geräte, wobei davon nicht alle auf der Seite landen – war das HTML entsprechend groß geworden. Es waren 1,92 MB reines HTML zusammengekommen. Dazu kommt noch etwas CSS und minimal Javascript, doch das CSS war bereits optimiert worden. Die Bilder der Telefone spielen beim Traffic keine Rolle, die kommen vom CDN von ifixit.
Knapp 2MB ist viel. Das bedeutet, dass schon 25.000 Seitenaufrufe genug waren um die Trafficwarnung zu produzieren. Eine so große Seite ist auch ein Performanceproblem, das alles will heruntergeladen und muss vom Browser interpretiert werden, was Zeit kostet.
Da das HTML direkt aus zwei ERB-Templatedateien entsprang, war es aber auch größer als nötig. Beispielsweise waren alle Leerzeilen enthalten, die im ERB-Code hilfreich sind, beim Lesen des HTML aber keinen Wert haben. Das ließ sich optimieren; das Stichwort ist HTML-Minifizierung. Ich bediente mich dabei dem Gem htmlcompressor, einem alten Projekt, das aber einwandfrei funktionierte: Aus 1,92 MB wurden 0,77 MB. Weniger als die Hälfte! Entsprechend häufiger kann die Seite aufgerufen werden, ohne über die Trafficgrenze zu rutschen.
Eine zweite kleinere Maßnahme folgte: Sustaphones benutzte eine Handvoll Icons von Font Awesome. Das zugehörige CSS war bereits aufs notwendige reduziert worden, aber die Fontdatei selbst war noch die vollen 80 KB. Die hätte nun ebenfalls zurechtgestutzt werden können. Stattdessen ersetzte ich die Icons durch Unicodesymbole – eine Lupe für die Suche, ein Dropdownpfeil, eine ausgefüllte Checkbox, ein Warndreieck und ein verneinendes X, das war alles vorhanden und wurde in meinen Tests sowohl unter Linux als auch unter Android angezeigt. Dadurch wurden weitere ~80 KB eingespart.
Schau selbst, links vorher, rechts nachher:
Cloudflare
Zusätzlich schaltete ich Cloudflare zwischen die Besucher und die Seite. Dafür überträgt man Cloudflare die Aufgabe, den Nameserver der Seite zu stellen. Anstatt per DNS direkt auf den Server zu zeigen verweist der Dienst dann auf die eigenen Server, die auf der Welt verteilt sind. Dadurch kann die Ladezeit reduziert und können unliebsame Besucher herausgefiltert werden. Außerdem bietet Cloudflare einen Cache an, von dem ich mir bei einer einzelnen statischen Seite viel versprach. Gleichzeitig kann man direkt dort die Domain hosten lassen, eine der kostengünstigsten Möglichkeiten aus meinem Artikel zum günstigen Hosten von Webseiten (der Jahrespreis sank von ~20€ bei Netlify auf ~10€ bei Cloudflare).
Die Domain bei Netlify rauszulösen war etwas umständlich. Ich musste bei Name.com einen Account anlegen, dem Support bei Netlify dessen Accountnummer mitteilen, und nach dem Transfer dorthin die Domain weiter zu Cloudflare transferieren. Immerhin, das wäre nicht nötig gewesen um nur Cloudflare einzusetzen, da hätte das Wechseln des Nameservers gereicht.
Bei Cloudflare bekam ich dann zum ersten Mal eine Statistik über die Zugriffe. Es stellt sich heraus, dass viele der Aufrufe von einzelnen Benutzern zu kommen scheinen. Eventuell Bots, wie Googles Crawler, die sich an der Seite verheddern?
Das war hilfreich, dagegen funktionierte der Cache zuerst nicht. Die Dokumentation verriet: Um HTML zu cachen muss das mit eine Konfigurationsregel erstmal aktiviert werden, ansonsten würde nur CSS, Javascript und Bilder im Cache landen. Mit der Regel war der Effekt dann enorm, klar, so eine simple HTML-Seite ist das perfekte Szenario für einen Zwischenspeicher. Die mehr als 1 GB Traffic am Tag stemmt nun Cloudflare fast zu 100%.
Pagination
Durch den Erfolg mit Cloudflare sind wahrscheinlich keine weiteren Maßnahmen notwendig. Die Seite aufzusplitten wäre aber eine Möglichkeit gewesen.
Derzeit bekommt jeder Besucher so eine große HTML-Seite präsentiert, weil es keinerlei Unterteilung gibt. Das ließe sich ändern, beispielsweise könnte Sustaphones nur die ersten 20 Telefone anzeigen, dann die nächsten 20 auf der nächsten Seite usw. Problem hierbei ist, dass die Liste der Telefone derzeit durchsucht und gefiltert werden kann. Das wäre dann nicht mehr umsetzbar, ohne im Hintergrund einen Server am Laufen zu haben oder Javascript vorauszusetzen. Beides will ich nicht, nicht für dieses Projekt, denn die technisch simple Umsetzung war bisher ein guter Leitsatz.
Daher habe ich eine Einbindung von Pagination verworfen, es hätte aber wahrscheinlich bei der Trafficvermeidung geholfen und gehörte daher erwähnt.
Gitlab Pages
Näher an der Umsetzung war ein Hosterwechsel. Der Code, mit dem Sustaphones gebaut wird, landet genau wie das erstellte HTML bei Gitlab (von wo es dann Netlify auf einen Server zieht). Gitlab kann aber mit Pages – genau wie Github – Seiten auch selbst ausliefern. Zumindest statische Seite, die keinen dynamischen Server im Hintergrund brauchen, was aber zu Sustaphones perfekt passt. Das tolle daran: Gitlab hat derzeit überhaupt keine offizielle Trafficbegrenzung. Vll würden sie sich bei absoluter Großnutzung melden, aber 50GB sind lächerlich klein (und 100GB kosten auch niemanden 55 USD, daher mein Erstaunen über den Preis oben).
Was mich davon abhielt war IPv6. Gitlab selbst kann das, hat es aber für diese Funktion auf Gitlab.com nicht aktiviert. Letzten Endes hätte es keine Auswirkungen, Cloudflare würde meines Wissen sogar Zugriff per IPv6 herstellen, aber ich empfand das deswegen thematisch unpassend.
Nun ist alles wieder gut. Die Optimierungen am HTML der Seite reduzieren den realen Trafficverbrauch, durch Cloudflare als Cache landen selbst davon beim Hoster nur noch wenige MB. Gleichzeitig lädt Sustaphones für Besucher nun schneller und der Wechsel der Icons half in meinen Augen sogar der Optik. Mit Gitlab steht ein kostenloser Hoster bereit, falls mit Cloudflare etwas schiefgeht oder ich das von Netlify ausgehende Kostenrisiko senken will (so sind Opfer von DOS-Angriffen bei Netlify wegen dem Traffic bereits in üble Kostenfallen gelaufen).
Um auf die Eingangsfragen noch Teilantworten zu geben: Die Seite war zu groß, aber da war sicher ein Crawler im Spiel, der sich an dem HTML verschluckt und die Seite unnötig oft aufruft. Aus der Kombination stammt der Traffic. Und Netlifys Trafficpreis ist meiner Wahrnehmung nach so hoch, weil der Hoster sich als Premiumoption aufstellt, der mit für Entwickler komfortable Funktionen punkten will. Danach soll, ähnlich wie damals bei Heroku, der Preis von den entsprechenden Firmen klaglos gezahlt werden, selbst wenn er (meines Wissens) mindestens zehnfach überhöht ist. Das bisher genutzte kostenlose Grundangebot ist daher natürlich ein Lockangebot, aber riskanter als anfangs erwartet.
