Bolt.new-Performance: gib Bolt ein Tempo-Budget, das es an einem echten Browser misst
Bolt baut JavaScript-Apps, und fast jeder Prompt fügt etwas hinzu, das der Browser herunterladen muss: eine Bibliothek, eine Komponente, ein Bild, eine Schrift. Nichts davon macht die Seite kaputt, also merkst du es erst, wenn sie sich auf dem Smartphone langsam anfühlt. Relvatos MCP-Connector gibt Bolt eine Messung, an der es nichts zu deuteln gibt — Core Web Vitals aus einem echten Chrome auf der veröffentlichten Website — samt den Gründen hinter jeder Zahl, damit Bolt in derselben Sitzung den richtigen Code ändert.
Warum Bolt-Apps mit jedem Prompt langsamer werden
Bolt wählt zu Beginn ein JavaScript-Framework wie React oder Vue, und alles, was die App tut, landet als JavaScript im Browser. Jede neue Abhängigkeit vergrößert das Bundle, das das Smartphone herunterladen und ausführen muss, bevor die Seite reagiert — das zeigt sich als Total Blocking Time und als langsamere Interaction to Next Paint. Große Bilder oben auf der Seite treiben den Largest Contentful Paint hoch. Webfonts und spät geladene Inhalte lassen das Layout springen: Cumulative Layout Shift.
Ein schneller Laptop im guten WLAN versteckt das alles. Relvatos Lauf auf dem Smartphone nicht: Er drosselt das Netz auf Slow 4G und die CPU um das Vierfache, wie PageSpeed, also zeigt sich eine Verschlechterung im ersten Lauf nach dem Prompt, der sie verursacht hat.
Bevor du anfängst
Die Website muss veröffentlicht und öffentlich sein. Bolt Cloud gibt jedem Projekt eine kostenlose *.bolt.host-Adresse, oder du verbindest eine eigene Domain; Projekte, die vor Mitte August 2025 veröffentlicht wurden, laufen womöglich noch bei Netlify unter *.netlify.app. Eine private Bolt-Website, die nur Eingeladene sehen, lässt sich von außen nicht messen.
Außerdem muss die Website in Relvato sein und ihre Inhaberschaft nachgewiesen — füge sie als Verbindung Any website / AI-built app hinzu und nutze die Meta-Tag-Methode (Bolt kann das Tag für dich in den head der Seite setzen) oder einen DNS-Eintrag. Nur der Projektinhaber in Bolt kann MCP-Server verbinden und Bolt bitten, sie zu nutzen.
Wenn du schon in Relvato bist, füge auch den Uptime-Monitor hinzu: Der Free-Tarif von Bolt liefert eine Website nicht mehr aus, sobald das Konto sein monatliches Datenlimit erreicht — für deine Besucher sieht das wie ein Ausfall aus.
Schritt 1 — Ein API-Schlüssel mit vollem Zugriff, nur für Bolt
Öffne in Relvato über das Kontomenü API access. Nenne den Schlüssel „Bolt“ und wähle unter What the key may do die Option Full access — ein Read-only-Schlüssel kann keinen Lauf starten. Klicke auf + Create API key und kopiere ihn sofort; er wird nur einmal angezeigt und beginnt mit rlv_.
Nutze diesen Schlüssel nur für Bolt. Willst du Bolt irgendwann trennen, widerrufst du seinen Schlüssel, und deine anderen Integrationen laufen weiter.
Schritt 2 — Relvato als eigenen Connector hinzufügen
Klicke auf der Bolt-Startseite im Chatfeld auf das Plus-Symbol, dann auf Connectors → Manage connectors. Klicke auf der Seite Connectors (MCP) auf Custom MCP server und fülle aus: Name — Relvato; URL — die Adresse unten; Transport type — HTTP (Relvato spricht Streamable HTTP, nicht SSE); Authentication — API key, dann deinen rlv_-Schlüssel einfügen. Klicke auf Connect und warte auf den Status Connected.
Relvato nimmt den Schlüssel entweder als Header Authorization: Bearer oder als Header x-api-key an — wie auch immer Bolt ihn sendet, es funktioniert. Lass Auto-enable for all projects vorerst aus: Du schaltest Relvato nur in den Projekten ein, in denen du es willst.
https://app.relvato.com/api/mcp
Schritt 3 — Nur die Tools behalten, die Bolt braucht
Jeder aktive Connector wird zum Kontext des Projekts hinzugefügt, und laut Bolt kann das langsamer machen und mehr Tokens verbrauchen. Relvatos Server bietet zwölf Tools; für eine Tempo-Schleife braucht Bolt sechs. Öffne das Drei-Punkte-Menü des Connectors → Edit und lass unter Tools list_sites, site_overview, add_checks, trigger_scan, get_run und get_fix_prompt eingeschaltet. Schalte die anderen aus und klicke auf Save changes.
Die Tool-Schalter gelten für jedes Projekt, das den Connector nutzt. Soll Bolt später eine neue Website hinzufügen oder den Zeitplan eines Monitors ändern, schalte diese Tools wieder ein und klicke auf Refresh connection.
Schritt 4 — Im Projekt einschalten und den Monitor hinzufügen
Klicke im Projekt im Chatfeld auf das Plus-Symbol → Connectors und schalte Relvato ein. Schreib dann: „Füge Relvatos Core-Web-Vitals-Monitor zu meiner Website hinzu.“ Bolt ruft add_checks mit dem Monitor web-vitals auf. Er misst die Startseite (oder eine andere Seite, die du in seinen Einstellungen in Relvato wählst) auf Smartphone und Desktop, je dreimal geladen, und behält den Median.
Schritt 5 — Ein Tempo-Budget in den Prompt schreiben
Zahlen helfen nur gegen eine Linie. Gib Bolt die Linie im Prompt vor — die Schwellen unten sind die, bei denen Relvato selbst warnt, also bedeutet „bestanden“ in Bolt und in Relvatos Dashboard dasselbe. Veröffentliche zuerst (Publish → Update) und schick dann einen Prompt wie den unten.
Bolt startet den Lauf mit trigger_scan und liest ihn mit get_run, bis er fertig ist, meist innerhalb einer Minute. Bolt dokumentiert keine Freigabe pro Aufruf für Connector-Tools, also sind die Tool-Schalter aus Schritt 3 deine Kontrolle: Bolt kann nur nutzen, was du eingeschaltet gelassen hast. Jeder Lauf zählt zu den monatlichen Läufen deines Relvato-Tarifs.
Starte nach dem Veröffentlichen Relvatos Core-Web-Vitals-Monitor auf meiner Website. Werte ihn als fehlgeschlagen, wenn auf dem Smartphone LCP über 2,5 s, CLS über 0,1 oder TTFB über 0,8 s liegt. Zeig mir das LCP-Element, die render-blockierenden Skripte und das größte ungenutzte JavaScript.
Schritt 6 — Aus der Diagnose Code-Änderungen machen
Ein Relvato-Lauf liefert mehr als Werte. Für jedes Gerät nennt er das Element, das der Largest Contentful Paint war, und wie sich seine Zeit auf Serverantwort, Laden der Ressource und Rendern verteilt; die Elemente, die das Layout verschoben haben; die Skripte, die das Rendern blockiert haben; zu große Bilder; und wie viel jeder JavaScript-Datei ungenutzt blieb. Jedes davon zeigt auf einen anderen Fix — die Tabelle unten ordnet sie zu.
Bitte Bolt, das Schlimmste zu beheben, veröffentliche mit Update und starte den Monitor erneut. Hat die Änderung die Zahl nicht bewegt, sagt der Lauf es dir — und du hast einen Prompt investiert statt einer Woche mit einer langsameren Website. Für einen fehlgeschlagenen Lauf liefert get_fix_prompt dasselbe Briefing, das Relvatos Button Suggest a fix nutzt.
Zwischen den Bolt-Sitzungen weiter beobachten
Der Connector misst, wenn du fragst. Um eine Verlangsamung zu bemerken, die du nicht verursacht hast — ein Drittanbieter-Skript, eine CDN-Änderung —, gib dem Monitor in Relvato einen Zeitplan (tägliche Läufe brauchen den Business-Tarif; mit Pro führt eine GitHub-Verbindung deine Monitore bei jedem Push erneut aus).
Laborwerte sind ein Browser mit einem Profil. Um zu sehen, was deine echten Besucher erleben, füge Relvatos Web Vitals echter Nutzer per Beacon hinzu — ein einzeiliges Skript, das Bolt für dich in die Seite setzen kann.
Relvatos Schwellen als Budget und der übliche Fix in einer Bolt-App
| Metrik | Relvato warnt ab | Relvato schlägt fehl ab | Übliche Ursache → Fix in einer Bolt-App |
|---|---|---|---|
| Largest Contentful Paint | 2,5 s | 4 s | Ein großes Hero-Bild oder Inhalt, der erst nach dem JavaScript rendert → Bild verkleinern und komprimieren, vorladen, Hero rendern, ohne auf Daten zu warten |
| Cumulative Layout Shift | 0,1 | 0,25 | Bilder ohne Breite und Höhe, wechselnde Schriften, spät eingefügte Banner → Maße setzen, Platz reservieren, font-display nutzen |
| Time to First Byte | 0,8 s | 1,8 s | Hosting, Weiterleitungen oder eine Serverfunktion bei der ersten Anfrage → kein Problem der Code-Größe; Domain-Einrichtung und Caching prüfen |
| Interaction to Next Paint | 200 ms | nur Warnung (500 ms ist schlecht) | Schwere Klick-Handler und ein großes Bundle → Code aufteilen, nicht kritische Arbeit verschieben |
| Total Blocking Time | angezeigt, nicht bewertet | — | Render-blockierendes und ungenutztes JavaScript → Routen und Komponenten lazy laden, ungenutzte Bibliotheken entfernen |
FAQ
Fragt Bolt, bevor es ein Relvato-Tool nutzt?
Bolt dokumentiert keinen Freigabeschritt für Connector-Tools. Steuere, was es darf, über die Tool-Schalter am Connector: Relvatos lesende Tools lesen nur, und trigger_scan startet nur Monitor-Läufe — nichts im Connector löscht oder ändert deine Website.
Welche Adresse soll ich messen?
Die, die deine Besucher nutzen: deine eigene Domain, wenn du eine verbunden hast, sonst die *.bolt.host-Adresse, die Bolt dem Projekt gegeben hat (oder *.netlify.app bei einem älteren Projekt, das noch bei Netlify liegt). Miss nach Publish → Update, damit der Lauf deine letzte Änderung sieht.
Macht der Connector Bolt langsamer oder verbraucht er mehr Tokens?
Etwas: Ein aktiver Connector ist Teil des Projektkontexts. Sechs eingeschaltete Tools und Relvato nur in den Projekten, die es brauchen, halten das klein.
Können Personen, mit denen ich das Projekt teile, es nutzen?
Nicht über deine Verbindung. Nur der Projektinhaber kann MCP-Server verbinden und Bolt bitten, sie zu nutzen.
Ist das dasselbe wie PageSpeed Insights?
Ähnlich, nicht identisch. Relvatos Lauf auf dem Smartphone nutzt dasselbe Drosselungsprofil (Slow 4G, 4× CPU) und meldet dieselben Metriken, behält aber den Median von drei Ladevorgängen und läuft von Relvatos eigenen Servern — rechne mit Werten im selben Bereich, nicht mit exakt denselben.