Netlify Edge Functions laufen inzwischen in eigenen Firecracker-MicroVMs statt in V8-Isolaten bei einem externen Dienstleister. Der Aufschlag pro Aufruf sinkt im Median von 25 bis 40 auf 5 bis 6 Millisekunden. Einen Teil des Tempos bringt allerdings schlicht der kürzere Weg, denn die Anfrage verlässt das Netz von Netlify nicht mehr.
drweb.de als bevorzugte Quelle auf Google hinzufügenQualitätsgeprüfte Inhalte direkt in Google News & DiscoverJetzt hinzufügen
Netlify beziffert die täglichen Aufrufe seiner Edge Functions auf rund eine Milliarde.[1] Der Reiseanbieter Sunweb personalisiert damit Seiten, die Lotteriegesellschaft Loto-Québec leitet Besucher anhand eines Cookies weiter. Jede dieser Funktionen läuft am Rand des Netzes vor der eigentlichen Website, jede Millisekunde Laufzeit verlängert also die Wartezeit auf das erste Byte.
Das Wichtigste in Kürze
- Netlify führt jede Edge Function in einer eigenen Firecracker-MicroVM im eigenen Netz aus, ohne Umstellung für Kunden und zum selben Preis.
- Ein warmer Aufruf kostet im Median 5 bis 6 statt bisher 25 bis 40 Millisekunden.
- Einen Teil des Gewinns bringt der entfallene Umweg über das Internet, den Anteil schlüsselt Netlify nicht auf.
- Die MicroVM pro Deploy trennt fremden Code härter als ein V8-Isolat, das Spectre-Angriffe nicht zuverlässig abwehrt.
Woher kommt das fünffache Tempo?
Kürzerer Weg. Bisher verließ jede Anfrage mit Edge Function das Netz von Netlify, lief über das Internet zu einem gehosteten Ausführungsdienst und kam von dort zurück.[1] Zum Start 2022 liefen die Edge Functions auf der Infrastruktur von Deno Deploy.[2] Heute reicht der nächstgelegene Knoten im Content Delivery Network von Netlify die Anfrage an einen Rechenknoten in der eigenen Infrastruktur weiter.
Gleiche Laufzeit. Unikraft, der Lieferant der MicroVM-Plattform, schreibt, dass Deno die Laufzeitumgebung blieb, jetzt als eigener Build von Netlify innerhalb der MicroVM.[3] Die V8-Engine arbeitet also weiter, nur nicht mehr als einzige Trennwand zwischen den Kunden. Die Messwerte vergleichen deshalb zwei Wege, nicht bloß zwei Techniken. Wie viel vom Sprung auf rund 6 Millisekunden auf die gesparte Internetstrecke entfällt, schlüsselt Netlify nicht auf.
Schnappschuss statt Kaltstart. Jede Funktion bekommt eine eigene Firecracker-MicroVM mit abgespecktem Linux, die in 99 Prozent der Fälle nach höchstens 2 Millisekunden läuft. Sobald der JavaScript-Server auf seinem Port lauscht, erstellt Netlify einen Schnappschuss der VM. Ruht die Funktion, baut die Plattform deren MicroVMs ab und startet beim nächsten Aufruf eine neue aus diesem Abbild.[1] Echte Kaltstarts betreffen 1,2 Prozent der Aufrufe und dauern im Schnitt 9 Millisekunden.
Warum genügt ein V8-Isolat als Trennwand nicht?
Eine VM pro Deploy. Zwei Deploys mit unterschiedlichem Code oder unterschiedlichen Umgebungsvariablen teilen sich bei Netlify nie eine MicroVM. Selbst ein Ausbruch aus der Laufzeit soll so weder andere Kunden noch die Rechenschicht erreichen. V8-Isolaten spricht Netlify diese Trennschärfe ausdrücklich ab.[1]
Spectre als Vorgeschichte. Das V8-Team bei Google kam schon 2019 zu dem Schluss, dass nicht vertrauenswürdiger Code per Spectre im Prinzip den gesamten Adressraum seines Prozesses auslesen kann. Als einzig wirksame Abwehr nannte das Team, sensible Daten in getrennte Prozesse zu verlagern.[4] Bei Cloudflare Workers laufen viele Kunden als Isolate in einem gemeinsamen Prozess. Im August 2026 legte Cloudflare offen, dass Forscher dort in der Produktion bis zu 12 Bit pro Sekunde mit 99 Prozent Trefferquote ausgelesen hatten,[5] darunter das JSON Web Token eines fremden Kunden.
Branchentrend. MicroVMs setzen sich überall dort durch, wo fremder Code läuft: AWS bietet Sandboxen für KI-Agenten auf Lambda an, Docker kapselt Agenten in isolierten Einweg-Umgebungen. Ein Allheilmittel ist auch die härtere Trennung nicht, wie im September Datenreste fremder Kunden in Cloudflares Containern zeigten.
Hinter dem fünffachen Tempo steckt auch der Umweg, den Netlify sich jetzt spart. Bleibenden Wert schafft die eigene MicroVM pro Deploy, denn spätestens seit dem Spectre-Angriff auf Cloudflare Workers taugt ein V8-Isolat nicht als Mandantengrenze.
Markus Seyfferth, Chefredakteur Dr. Web
Vorher und nachher im Vergleich
Was sollten Website-Betreiber jetzt prüfen?
Technik aus Heidelberg. Unikraft, eine Ausgründung aus dem Heidelberger Forschungslabor von NEC, liefert die MicroVM-Plattform.[6] Netlify verantwortet Lastverteilung und Platzierung selbst, vom Heidelberger Anbieter stammen Bootvorgang, Schnappschüsse und das Abschalten ruhender MicroVMs.[1][3]
Vier Prüfpunkte. Für Unternehmen, die Personalisierung, Weiterleitungen oder Logins über Edge Functions abwickeln, lohnt ein kurzer Check:
- Schlüssel, Token und Zufalls-IDs pro Anfrage erzeugen, nicht beim Modulstart. Die Firecracker-Dokumentation warnt, dass Klone aus einem Schnappschuss Zufallszustände teilen können, und rät von Zufallswerten in der Logik vor dem Schnappschuss ab.[7]
- Die Antwortzeit messen: Google empfiehlt eine Time to First Byte von höchstens 0,8 Sekunden,[8] und jede Edge Function zählt mit. Hintergrund liefern unsere Beiträge zu den Core Web Vitals und zur Rolle des Hostings beim Pagespeed.
- Den Auftragsverarbeitungsvertrag prüfen. Netlifys Liste der Unterauftragsverarbeiter nennt durchweg US-Standorte, Deno und Unikraft tauchen darin nicht auf.[9] Für personenbezogene Daten in Edge Functions gehört der Drittlandtransfer in die DSGVO-Dokumentation.
- Neue Projekte nicht an den alten Grenzen ausrichten. Netlify will die Limits aus dem Isolat-Modell überprüfen und npm-Pakete in Edge Functions aus der Beta holen.[1]
Kein Handlungsdruck. Bestehende Projekte laufen ohne Änderung weiter. Agenturen, deren Kunden Datenstandort und Mandantentrennung ausschreiben, finden europäische Alternativen im Webhosting-Vergleich.
Quellen
[1] Netlify: „5x faster Edge Functions: How we replaced v8 isolates with Firecracker MicroVMs“ (29.09.2026)
[2] Deno: „Netlify Edge Functions on Deno Deploy“ (19.04.2022)
[3] Unikraft: „How Netlify Runs all of Edge Functions on Unikraft microVMs“ (29.09.2026)
[4] V8: „A year with Spectre: a V8 perspective“ (23.04.2019)
[5] Cloudflare: „A revisit of remote Spectre attacks on Cloudflare Workers“ (19.08.2026)
[6] Technologiepark Heidelberg: „Success Story: Unikraft“
[7] Firecracker (GitHub): „Entropy for Clones“
[8] web.dev (Google): „Time to First Byte (TTFB)“
[9] Netlify: „Subprocessors“ (abgerufen am 01.10.2026)
Mehr Newshunger?
- Cloudflare Workers: Ein Spectre-Angriff las das JWT eines fremden Kunden
- Cloudflare-Container: Wiederverwendete Speicherblöcke verrieten Datenreste fremder Kunden
- MicroVMs: AWS Lambda startet Sandboxen für KI-Agenten
- Docker Sandboxes: isolierte Einweg-Umgebungen für KI-Agenten
- Wie Cloud-Browser dank Firecracker in unter einer Sekunde starten
- celld ersetzt Cloudflares Backend: Durable Objects auf eigenen Servern
- Telekom und Cloudflare verbinden ihre Netze direkt: Der Umweg über Transitanbieter entfällt
