Renders kleines Geheimnis - 6 JAMStack Platformen im Vergleich
Unser Fokus liegt darauf, Websites mit sehr hoher Performance zu bauen. Das ist einer der Hauptgründe, warum wir die Konzepte des JAMStack anwenden, sprich statische Seiten bauen. Es gibt eine handvoll Anbieter, die einem das Lebens als Entwickler erleichtern wollen und Lösungen anbieten, mit denen man im Handumdrehen statische Seiten online stellen kann.
Wir bauen die Platform eines Kunden von Grund auf neu. Es handelt sich um ein Branchenverzeichnis, welches aktuell über 25.000 eingetragene Unternehmen bewirbt und für jedes dieser Unternehmen eine eigene Seite beinhaltet. Dabei bewegen wir uns von einer traditionellen PHP-Server-Lösung hin zu einem modernen JAMStack.
Während ein solcher Aufbau für eine klassische MVC-Lösung relativ unproblematisch ist, ist der JAMStack hier herausgefordert. Der Grund, warum wir unbedingt eine statische Website bauen möchten liegt in der gesteigerten Performance, die aus SEO-Perspektive so wichtig ist.
Wir haben die folgenden Anbieter verglichen:
und die meisten sind - aus sehr unterschiedlichen Gründen - an der Herausforderung gescheitert. Hier ist die Kurfassung in Form einer Tabelle.
| Anbieter | PageSpeed Mobile | 25.000 Seiten bauen? | Monatlich kostenlos |
|---|---|---|---|
| Amazon Amplify | 76 - 89 Punkte | 6min 42s | 1000 Build-Minuten |
| DigitalOcean App Platform | - | Timeout bei 60min | 100 Build-Minuten |
| Cloudflare Pages | 87 Punkte | Error (20k Assets Limit) | 500 Builds |
| Netlify | 82 Punkte | Timeout bei 32 min | 300 Build-Minuten |
| Render | 83 - 88 Punkte | 26min 15s | unbegrenzt |
| Vercel | - | - (16k Assets Limit) | - |
Wir haben unsere Web App von jedem dieser Anbieter (außer Vercel - dazu später mehr) bauen lassen. Dann haben wir mit Google’s PageSpeed die jeweilige Startseite mindestens 3 mal getestet. Außerdem haben wir zwei Varianten unserer Website getestet: mit dynamischem Routing und mit statischen Seiten für die 25.000 Seiten. Beim Bauen von so vielen Seiten sind die meisten Anbieter gescheitert. Amazon brilliert, Render überrascht.
Cloudflare Pages ist leider noch nicht gut genug
Zunächst haben wir mit großer Hoffnung auf Cloudflare gesetzt. Die Vorteile des weltweit größten CDN liegen auf der Hand. Die niedrige Latenzzeit ist für Web-Projekte mit hoher SEO-Relevanz von großem Vorteil.
Man findet online allerlei Erfahrungsberichte und Vergleiche zwischen Netlify und Cloudflare, die Cloudflare eine deutlich höhere Performance nachsagen. Ein Beispiel: https://pustelto.com/blog/how-and-why-i-have-migrated-from-netlify-to-cloudflare/
Trotzdem sind wir mit Cloudflare Pages nicht zum Ziel gelangt. Denn es gibt ein Limit von maximal 20.000 Assets. Da wir über 20.000 Seiten benötigen, und jede Seite eine eigne HTML Datei sein soll, funktioniert Cloudflare für uns nicht.
Man könnte nun argumentieren, dass es ja auch übertrieben sei, 20.000 Seiten zu bauen, wenn man stattdessen auch dynamisches Routing verwenden könnte. Das bedeutet, dass man nur eine Seite baut und wenn der Nutzer nun eine der über 20.000 URLs öffnet, diese eine Seite aufgerufen wird. Dann wäre es allerdings so, dass die Inhalte nach dem Öffnen der Seite nachträglich erst geladen werden müssten. Und dieser Vorgang kostet viel Zeit.
Dennoch haben wir es versucht. Hierfür muss der Server so konfiguriert werden, dass er jede URL, die ein solches Muster hat, in unserem Fall /eintrag/* an diese eine HTML-Seite weitergeleitet wird. Allerdings funktioniert auch dies nicht mit Cloudflare Pages, denn Cloudflare entfernt immer das .html am Ende einer URL, was dazu führt, dass es zumindest mit unserem favorisierten Frontend-Framework nicht funktioniert. Hinzu kommt, dass Cloudflare bislang keinen Status Code 200 in den URL rewrites unterstützt.
Und an diesen beiden Gründen scheitert die Nutzung von Cloudflare Pages mit über 20.000 Seiten.
Netlify hätte es werden können, Amazon hat mehr Kraft
Da Vercel ein noch geringeres Limit hat, haben wir das gar nicht erst versucht. Netlify hingegen hat kein solches Limit.
Bei Netlify funktioniert die Lösung mit dynamischem Routing direkt sehr gut. Auch der PageSpeed Rank ist kaum schlechter als bei Cloudflare, deutlich weniger als befürchtet. Allerdings hat das dynamische Nachladen der Inhalte zur Folge, dass der PageSpeed-Wert auf den 25.000 Seiten der eingetragenen Unternehmen stark leidet. Und das ist für uns keine Option. Aus diesem Grund haben wir dann versucht, wieder unsere 25.000 Seiten zu bauen. Und Netlify gibt sich wirklich Mühe. Allerdings wird der Vorgang nach 32 Minuten abgebrochen wegen eines Timeouts.
Amazon Amplify ist jedoch deutlich besser. Hier werden wohl deutlich stärker ausgestattete Maschinen verwendet, die es möglich machen, in nur 6 Minuten und 42 Sekunden die gesamte Seite zu bauen und zu veröffentlichen. Das ist gar nicht schlecht in Anbetracht der Tatsache, dass man 1000 kostenlose Build-Minuten im Monat erhält. In unserem Fall sind das ca. 140 Builds pro Monat, also zwischen 4 und 5 Builds pro Tag, die kostenlos sind.
Eine JAMStack Website muss in aller Regel dann einen neuen Build-Prozess durchlaufen, wenn sich die Inhalte geändert haben. Daher ist es insbesondere in Anwendungsfällen, in welchen sehr häufige Änderungen an einer Seite durchgeführt werden, relevant, dass dieser Prozess auch schnell geht. 7 Minuten sind hier eine durchaus gute Zeit in Anbetracht des hohen Aufwands.
Amazon ist hinsichtlich des PageSpeed Rankings etwas schlechter als Cloudflare.
Render verheimlicht sein CDN, aber das lässt sich ermitteln
Zu guter Letzt haben wir noch Render getestet - und der einzige Grund bestand darin, dass es einfach immer kostenlos ist, solange man nicht 100GB Datentransfer übersteigt. Und das wird sicherlich noch lange nicht passieren. Und dabei gab es zwei große Überraschungen.
Erstens hat der Build tatsächlich geklappt. Angesichts der zermürbenden Alternativ-Ergebnisse im Schatten von Amazon’s hervorrangender Leistung, hätten wir das nicht erwartet. 23 Minuten ist eine lange Zeit. Andererseits kann man diese aber akzeptieren, wenn man dafür wirklich nichts bezahlen muss.
Und zweitens sind die PageSpeeds überdurchschnittlich schnell. Laut den Marketing-Websites von Render wird hier ein globales CDN verwendet. Aber der Name des CDNs wird mit keinem Wort erwähnt und ist auch nach ausgiebiger Google Suche verborgen geblieben. Warum? Dürft ihr es nicht verraten?
Eine kleine traceroute Analyse aus Hamburg hat hier aber deutliche Klarheit gebracht. Der Name “aplicado.onrender.com.cdn.cloudflare.net” verrät hier schon, dass es sich um Cloudflare handelt. Wenn man sich den Vergleich zu unserer Seite auf Cloudflare anschaut, wird klar, dass es sich im Grunde um dieselbe Route handelt - bis auf den allerletzten Server. Die Seite wurde also auf jeden Fall aus Hamburg, aus dem Cloudflare System abgerufen.
Cloudflare ist als branchenführendes Unternehmen im CDN-Markt am besten aufgestellt und ist durchaus ein wichtiges Kriterium für uns. Daher ist es verwunderlich, dass man diese wertvolle Information mit keinem Wort erwähnt.
Render
traceroute aplicado.onrender.com
traceroute: Warning: aplicado.onrender.com has multiple addresses; using 216.24.57.3
traceroute to aplicado.onrender.com.cdn.cloudflare.net (216.24.57.3), 64 hops max, 52 byte packets
1 XXX.XXX.XXX.XXX (XXX.XXX.XXX.XXX) 6.840 ms 3.388 ms 3.027 ms
2 mx204-1.ham.purtel.com (185.39.84.7) 4.993 ms 5.173 ms 4.648 ms
3 100.83.140.114 (100.83.140.114) 12.920 ms
100.83.140.5 (100.83.140.5) 5.522 ms
100.83.140.114 (100.83.140.114) 10.996 ms
4 100.83.140.18 (100.83.140.18) 4.816 ms 4.929 ms
100.83.140.14 (100.83.140.14) 4.863 ms
5 et-0-0-59.edge1.hamburg1.level3.net (62.67.25.37) 4.805 ms 7.373 ms 9.652 ms
6 62.67.25.90 (62.67.25.90) 20.632 ms 59.607 ms 5.640 ms
7 216-24-57-3.ip.win.net (216.24.57.3) 4.824 ms 4.854 ms 4.727 msCloudflare
traceroute aplicado.pages.dev
traceroute: Warning: aplicado.pages.dev has multiple addresses; using 172.66.47.70
traceroute to aplicado.pages.dev (172.66.47.70), 64 hops max, 52 byte packets
1 XXX.XXX.XXX.XXX (XXX.XXX.XXX.XXX) 6.781 ms 2.876 ms 3.084 ms
2 mx204-1.ham.purtel.com (185.39.84.7) 4.253 ms 4.203 ms 4.181 ms
3 100.83.140.114 (100.83.140.114) 8.834 ms
100.83.140.5 (100.83.140.5) 4.701 ms
100.83.140.114 (100.83.140.114) 8.533 ms
4 100.83.140.18 (100.83.140.18) 4.373 ms 4.121 ms 4.084 ms
5 et-0-0-59.edge1.hamburg1.level3.net (62.67.25.37) 4.109 ms 4.383 ms 4.087 ms
6 62.67.25.90 (62.67.25.90) 4.824 ms 4.685 ms 5.113 ms
7 172.66.47.70 (172.66.47.70) 4.200 ms 6.215 ms 4.287 msIm folgenden ist eine Analyse der Netzwerk-Schritte zu unserer Seite auf Amazon Amplify. Es ist deutlich zu erkennen, dass wir unsere Seite hier mit viel mehr Zwischenstationen über hunderte Kilometer abrufen müssen, scheinbar aus Kopenhagen. Im Gegensatz dazu betreibt Cloudflare direkt in unserer Nähe in Hamburg einen Server-Standort, was natürlich sehr viel besser ist.
Amplify
traceroute aplicado.d3js8nnk6iy0w7.amplifyapp.com
traceroute: Warning: aplicado.d3js8nnk6iy0w7.amplifyapp.com has multiple addresses; using 143.204.238.88
traceroute to aplicado.d3js8nnk6iy0w7.amplifyapp.com (143.204.238.88), 64 hops max, 52 byte packets
1 XXX.XXX.XXX.XXX (XXX.XXX.XXX.XXX) 13.495 ms 4.449 ms 3.741 ms
2 mx204-1.ham.purtel.com (185.39.84.7) 3.276 ms 5.768 ms 4.377 ms
3 100.83.140.5 (100.83.140.5) 4.569 ms 4.466 ms 4.940 ms
4 100.83.140.18 (100.83.140.18) 5.261 ms
100.83.140.14 (100.83.140.14) 14.511 ms
100.83.140.18 (100.83.140.18) 4.515 ms
5 et-0-0-59.edge1.hamburg1.level3.net (62.67.25.37) 5.065 ms 18.693 ms 8.758 ms
6 ae-2-3201.ear1.copenhagen2.level3.net (4.69.148.190) 8.871 ms 8.906 ms 8.641 ms
7 telia-level3-200g.copenhagen2.level3.net (4.68.73.254) 14.236 ms 14.211 ms 14.460 ms
8 amazon-svc075454-ic364116.ip.twelve99-cust.net (213.248.84.199) 10.517 ms 15.438 ms 24.148 ms
9 52.93.139.72 (52.93.139.72) 11.618 ms
52.93.139.104 (52.93.139.104) 11.341 ms
52.93.139.136 (52.93.139.136) 12.499 ms
10 52.93.139.239 (52.93.139.239) 10.541 ms
52.93.139.237 (52.93.139.237) 10.662 ms
52.93.139.155 (52.93.139.155) 17.604 ms
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 server-143-204-238-88.cph50.r.cloudfront.net (143.204.238.88) 10.391 ms 10.786 ms 11.080 msTarife - Build-Minuten sind nicht vergleichbar
Wenn man stumpf zwischen den Angeboten von DigitalOcean, Netlify und Amazon vergleicht, schaut man nur auf die Anzahl der Build-Minuten. Bei Amazon Amplify muss man nach 1000 Build Minuten anfangen pro weitere Minute zu bezahlen. Bei DigitalOcean schon nach 100 Minuten, bei Netlify nach 300 Minuten. Cloudflare hingegen ignoriert die Dauer eines Builds und erlaubt einfach pauschal 500 Builds pro Monat.
Wie man bei unserem Test sieht, ist es keine gute Idee, Build-Minuten direkt zu vergleichen. Offensichtlich verwendet Amazon viel stärkere Server zur Durchführung des Builds, nämlich solche mit 4vCPUs und 7GB Arbeitsspeicher. DigitalOcean hingegen stellt nur 2 GB Arbeitsspeicher zur Verfügung.
Unser Build hatte 60 Minuten bei DigitalOcean gebraucht und wurde dann vom System abgebrochen. Das bedeutet, dass wir mit unserem einen einzigen Build bereits 60 von 100, also mehr als die Hälfte, des monatlichen Kontingents verbraucht haben. Auch Netlify hatte sehr viel länger gebraucht und war dann gescheitert. Hier hätten wir zumindest noch 9 Versuche gehabt.
Man sollte also beim Bewerten von Build-Minuten bedenken, dass die zugrundeliegende Serverleistung entscheidend dafür ist, wieviele Minuten ein Build tatsächlich dauert.
Flexibilität von Tarifen
Man bedenke auch, dass die Tarife von Amazon deutlich flexibler sind, weil jede weitere Build-Minute einzeln berechnet wird. DigitalOcean hingegen bietet 3 Pakete mit 100, 400 und 1000 Build-Minuten. Netlify macht es so, dass ein Überziehen der 300 Minuten automatisch zur Folge hat, dass ein Paket hinzugebucht wird, welches weitere 500 enthält und 7$ kostet.
Die Angebote der unterschiedlichen Anbieter unterscheiden sich auch stark hinsichtlich der Begrenzung des ausgehenden Traffics. Hier gibt es unterschiedliche Preise für Grenz-Überschreitungen. Diese waren in unserer Analyse erstmal kein zentraler Fokus, sollte man aber auch bedenken und vergleichen.
Fazit
Amazon und Render sind die Testsieger. Wer weniger Wert auf Performance legt, aber schnellere Builds benötigt, sollte sich an Amazon wenden. Wer hingegen nichts bezahlen möchte und seine Seite seltener ändert, dafür aber hohe SEO-Anforderungen zu erfüllen hat, ist mit Render sehr gut bedient.