Wie wir Vercel- und Neon-Usage auf ostheimer.at reduziert haben

Stand: 12. Mai 2026

Manchmal zeigt ein Dashboard sehr klar, wo die nächste technische Aufgabe liegt. Bei ostheimer.at war das Anfang Mai 2026 der Fall: Ein einzelnes Projekt verbrauchte fast die gesamte Vercel Function CPU-Zeit und praktisch die gesamte provisioned Memory Duration im Account.

Die Ursache war nicht eine einzelne große Funktion, sondern ein Muster: Seiten und Sprachvarianten wurden zu oft zur Laufzeit berechnet, und ein Emoji-API-Pfad lud für Facetten deutlich mehr Daten aus Neon Postgres, als für die Oberfläche nötig waren.

Ausgangslage

Im Vercel-Abrechnungszeitraum vom 19. April bis 19. Mai 2026 zeigte das Projekt ostheimer-at in der Ansicht Fluid Active CPU rund 113 Stunden und 48 Minuten, also 99,2 Prozent der gemessenen Nutzung. Bei Fluid Provisioned Memory waren es rund 958,1 GB-Stunden, also 99,3 Prozent.

Das war ein klares Signal: Wenn eine Website zwar schnell wirkt, aber zu viele Requests im Serverless-Pfad landen, steigen CPU, Memory und Datenbankzugriffe trotzdem unnötig.

Was wir geändert haben

Der erste Schritt war, die öffentlichen Emoji-Seiten und Sprachvarianten konsequent cachebar zu machen. Dazu haben wir die deutschen Standardrouten, die lokalisierten Sprachrouten und die wichtigen Emoji-Detail- und Taxonomie-Seiten so umgebaut, dass Next.js und Vercel sie als statische oder ISR-Seiten ausliefern können.

Konkret wurden unter anderem diese Bereiche verbessert:

• Emoji-Übersichtsseiten und Sprachvarianten werden statisch beziehungsweise per ISR ausgeliefert.
• Lokalisierte Emoji-Routen wie /en/emojis werden sauber auf cachebare Seiten gemappt.
• Dynamische Header-Zugriffe wurden aus kritischen Layout-Pfaden entfernt, damit sie nicht unnötig Static Rendering verhindern.
• Blog-, Service- und llms.txt-Routen wurden auf stabilere Cache-Strategien geprüft.
• Die interaktive Emoji-Suche bleibt dynamisch, läuft aber bewusst über /api/emojis statt die ganze Seite dynamisch zu machen.

Das Ziel war einfach: Besucherinnen und Besucher sollen fertige Seiten vom CDN bekommen. Nur echte Interaktion, Suche oder Filterung soll noch Server- und Datenbankarbeit auslösen.

Ergebnis bei Vercel

Nach den Cacheability-Änderungen war der Trend deutlich besser. In den Vercel-Tageswerten sank die Fluid Active CPU teamweit von 0,755823 am 9. Mai 2026 auf 0,315254 am 11. Mai 2026. Das entspricht grob 58 Prozent weniger CPU-Kosten in dieser Metrik.

Auch die Fluid Provisioned Memory Duration ging im selben Zeitraum von 0,185636 auf 0,078398 zurück. Für ostheimer-at lag der projektbezogene Tageswert am 11. Mai 2026 bei rund 1,027610 USD, davon 0,301133 für Fluid CPU und 0,066131 für Fluid Memory.

Live-Prüfungen zeigten danach, dass wichtige öffentliche Routen über Vercel als HIT oder STALE aus dem Cache kamen. Genau dort wollten wir hin.

Der zweite Engpass: Neon Postgres

Nach der Vercel-Entlastung wurde Neon sichtbarer. Die Datenbank selbst war gesund: rund 292 MB Datenbankgröße, 99,67 Prozent Cache-Hit-Rate, keine auffälligen Deadlocks oder temporären Dateien.

Der Hot Path lag aber in der Emoji-API. Besonders teuer war die Facettenberechnung für Tags. Vor der Optimierung wurden bei wiederholten API-Aufrufen sehr viele Relationen aus _EmojiTags sowie sehr viele Tag-Lokalisierungen geladen, obwohl die Oberfläche am Ende nur die wichtigsten sichtbaren Filter anzeigen muss.

Die Lösung: Zählen in der Datenbank, nicht im JavaScript-Prozess.

Statt alle Tag-Relationen zu laden und danach in Node.js zu zählen, aggregiert die API die Tag-Facetten jetzt direkt in Postgres. Kategorien und Unterkategorien laufen ebenfalls über Datenbank-Aggregationen. Anschließend werden nur die sichtbar relevanten Tags samt Lokalisierungen geladen.

Nach dem Deployment haben wir die Neon-Statistik zurückgesetzt und einen absichtlichen Cache-Miss auf /api/emojis ausgelöst. Das Ergebnis:

• _EmojiTags liefert jetzt 1.916 gruppierte Tag-Zeilen statt zehntausende Relationseinträge pro Standardaufruf.
• EmojiTagLocale lädt für den sichtbaren Filterbereich nur noch 81 Zeilen statt den gesamten Bestand.
• Der API-Response bleibt gleich: 3.772 Emojis insgesamt, 12 Einträge pro Seite im Test und 24 sichtbare Tags.
• Wiederholte API-Aufrufe werden von Vercel als HIT aus dem Cache beantwortet.

Warum das für Kundinnen und Kunden relevant ist

Performance-Optimierung ist nicht nur Lighthouse. Gute technische Arbeit reduziert auch die laufenden Betriebskosten und schützt Systeme vor unnötiger Last.

Für Projekte aus Webdesign und Entwicklung, KI-Integration oder datengetriebenen Tools ist das besonders wichtig: Eine Anwendung kann schön, schnell und trotzdem teuer sein, wenn sie bei jedem Request dieselbe Arbeit neu macht.

Die beste Optimierung ist oft unspektakulär: saubere Cache-Grenzen, statische Auslieferung dort, wo Inhalte stabil sind, und Datenbankabfragen, die nur genau die Daten holen, die wirklich gebraucht werden.

Nächste Schritte

Die aktuelle Code-Änderung ist deployed. Ab jetzt zählt die Live-Nutzung. Wir beobachten als Nächstes, ob /api/emojis weiterhin ein relevanter Hot Path bleibt oder ob sich die Last nun auf andere, tatsächlich dynamische Endpunkte verschiebt.

Falls die Neon-Statistik nach einigen Stunden Traffic noch ein klares Muster zeigt, wäre der nächste konkrete Schritt ein kleiner Runtime-Cache für häufige Emoji-API-Parameter wie limit=12 und lang=de. Aktuell ist das aber erst sinnvoll, wenn die neuen Messdaten zeigen, dass es weiterhin nötig ist.

Fazit

Die bisher wichtigste Verbesserung war nicht ein einzelner Trick, sondern die Trennung der Verantwortlichkeiten:

Statische Seiten gehören ins CDN. Dynamische Filter gehören in eine API. Aggregationen gehören in die Datenbank. Und teure Live-Metriken gehören regelmäßig überprüft, nicht nur nach Gefühl optimiert.

Genau diese Ordnung hat ostheimer.at in den letzten Tagen spürbar entlastet.