Sie haben eine ansprechende Website in Framer gebaut. Die Animationen laufen flüssig, das Design ist sauber, und auf dem MacBook Pro fühlt sich alles schnell an. Dann führen Sie einen PageSpeed-Test durch und sehen einen Score von 45.
Damit sind Sie nicht allein. Viele Framer-Websites schneiden bei Googles Core Web Vitals schlechter ab als erwartet, besonders auf Mobilgeräten. Die Ursachen sind strukturell, und die Handlungsoptionen sind begrenzt.
Die Performance-Zahlen
Aus Audits Dutzender Framer-Websites im letzten Jahr ergibt sich ein konsistentes Bild:
| Metrik | Framer-Durchschnitt | Googles "Gut"-Schwellenwert | Next.js-Durchschnitt |
|---|---|---|---|
| Mobiler PageSpeed-Score | 42-65 | 90+ | 92-99 |
| Largest Contentful Paint | 3,2-5,8s | Unter 2,5s | 0,8-1,5s |
| Total Blocking Time | 400-1.200ms | Unter 200ms | 10-80ms |
| Cumulative Layout Shift | 0,05-0,25 | Unter 0,1 | 0-0,02 |
Diese Wertebereiche stammen aus realen Framer-Business-Websites mit Animationen, CMS-Inhalten und eigenen Komponenten. Einfachere Websites können besser abschneiden, doch mehr Komplexität drückt die Scores zuverlässig nach unten.
Warum Framer-Websites langsam werden
Großes JavaScript-Bundle
Framer liefert auf jeder Seite eine umfangreiche JavaScript-Runtime aus. Diese Runtime trägt die Animation-Engine, das CMS-Rendering und das Komponenten-System. Selbst eine einfache Landing Page mit wenig Inhalt lädt 200-400 KB JavaScript, bevor der eigentliche Inhalt erscheint.
Auf einem Android-Mittelklassegerät mit 4G-Verbindung dauert das Parsen und Ausführen dieses JavaScripts 1-3 Sekunden. Bilder, Schriften und sichtbare Inhalte folgen erst danach.
Client-Side Rendering
Framer rendert Seiten primär im Browser: Erst kommt das HTML, dann das JavaScript, dann baut das JavaScript die Seite auf. Next.js sendet stattdessen fertig gerendertes HTML vom Server. Der Browser zeigt den Inhalt sofort, während JavaScript im Hintergrund lädt.
Das erklärt, warum Ihre Framer-Website auf dem Laptop schnell wirkt, bei PageSpeed aber schlecht abschneidet. Der Test simuliert ein echtes Mobilgerät mit echter Mobilverbindung, kein MacBook auf Glasfaser.
Aufwand durch Animationen
Framers Animationssystem ist leistungsfähig, aber kostspielig. Jede scrollgetriggerte Animation, jeder Hover-Effekt und jeder Seitenübergang erhöht die JavaScript-Ausführungszeit. Was auf dem Desktop flüssig wirkt, erzeugt auf Mobilgeräten mit weniger Rechenleistung sichtbare Ruckler.
Begrenzte Bildoptimierung
Framer bietet grundlegende Bildoptimierung, lässt jedoch keine Kontrolle über Formate, Qualitätsstufen oder responsive Sizing-Strategien zu. Next.js' Image-Komponente liefert WebP/AVIF automatisch in den passenden Dimensionen je Gerät, inklusive Lazy Loading und Blur-up-Platzhaltern. Allein bei der Bildgröße kann der Unterschied 50-80 % betragen.
Was Sie innerhalb von Framer tun können
Wer auf Framer bleiben möchte, hat einige sinnvolle Stellschrauben:
- Anzahl der Animationen reduzieren, da jede einzelne Performance kostet
- Bilder vor dem Upload komprimieren, statt auf Framers eigene Optimierung zu vertrauen
- Benutzerdefinierte Code-Overrides und eingebettete Scripts auf ein Minimum beschränken
- Ungenutzte Komponenten und Sektionen entfernen
- Tief verschachtelte Komponentenstrukturen vermeiden
Realistisch betrachtet lassen sich damit 10-15 Punkte herausholen. Wer bei 45 startet, landet bei 55-60. Das liegt immer noch unterhalb von Googles Schwellenwert für "gute" Performance.
Der geschäftliche Schaden
Google zieht Core Web Vitals als Rankingsignal heran. Schlechte mobile Performance bedeutet schlechtere Suchrankings. Über SEO hinaus verlassen 53 % der mobilen Besucher eine Website, die länger als 3 Sekunden zum Laden braucht (Google-Daten). Liegt der LCP Ihrer Framer-Website bei 4+ Sekunden, verlieren Sie Besucher, bevor diese Ihren Inhalt überhaupt sehen.
Für Websites, die auf organischen Traffic oder bezahlte Conversions angewiesen sind, schlägt schlechte Performance direkt auf den Umsatz durch. Jede zusätzliche Ladezeit von 100 ms senkt die Conversion-Rate um etwa 1 %.
Die Alternative
Ein Next.js-Rebuild übernimmt Ihr Design und behebt die zugrundeliegenden Performance-Probleme. Layout, Animationen und Markenidentität bleiben unverändert. Was sich ändert: Die Auslieferung wechselt von client-seitig gerendertem JavaScript zu server-seitig gerendertem HTML mit optimierten Assets.
In Migrationsprojekten ist der Sprung von 45-65 auf 92-99 beim mobilen PageSpeed-Score das übliche Ergebnis. Gleiches Design, deutlich bessere Performance: bessere Rankings, niedrigere Absprungraten, höhere Conversions.
Wenn Ihre Framer-Website ein Geschäftswerkzeug ist und kein reines Portfolio-Stück, verdient Performance Priorität. Testen Sie Ihre Website mit PageSpeed Insights auf Mobilgeräten und sehen Sie, wo Sie stehen. Die Zahlen zeigen, ob plattforminterne Optimierung ausreicht oder ob Sie an die Grenzen von Framers Architektur gestoßen sind. webvise zeigt Ihnen den nächsten Schritt: /#contact.