U heeft een prachtige site gebouwd in Framer. De animaties zijn vloeiend in de editor, het ontwerp ziet er gepolijst uit, en alles voelt snel aan op uw MacBook Pro. Dan voert u een PageSpeed-test uit en ziet u een score van 45.
U staat niet alleen. Veel Framer-sites scoren teleurstellend op Google's Core Web Vitals, met name op mobiel. Hier leest u waarom dat zo is en wat u eraan kunt doen.
De prestatiecijfers
In het afgelopen jaar zijn er tientallen Framer-sites geaudit. Het patroon is consistent:
| Metric | Framer gemiddelde | Google's drempel voor "goed" | Next.js gemiddelde |
|---|---|---|---|
| Mobiele PageSpeed-score | 42-65 | 90+ | 92-99 |
| Largest Contentful Paint | 3,2-5,8s | Onder 2,5s | 0,8-1,5s |
| Total Blocking Time | 400-1.200ms | Onder 200ms | 10-80ms |
| Cumulative Layout Shift | 0,05-0,25 | Onder 0,1 | 0-0,02 |
Dit zijn typische bandbreedtes voor Framer-bedrijfssites met animaties, CMS-content en maatwerk componenten. Eenvoudigere sites presteren soms beter, maar complexiteit drukt de scores omlaag.
Waarom Framer-sites traag kunnen zijn
Zware JavaScript-bundel
Framer stuurt een grote JavaScript-runtime naar elke pagina. Deze runtime voedt de animatie-engine, de CMS-rendering en het componentensysteem. Zelfs een eenvoudige landingspagina met minimale content laadt 200-400KB aan JavaScript voordat de daadwerkelijke content verschijnt.
Op een middenklasse Android-telefoon met een 4G-verbinding duurt het parsen en uitvoeren van dat JavaScript 1-3 seconden. Dat is voordat afbeeldingen laden, voordat lettertypen renderen, voordat de gebruiker iets nuttigs ziet.
Client-side rendering
Framer rendert pagina's voornamelijk aan de clientzijde. De browser downloadt HTML, vervolgens JavaScript, en vervolgens bouwt het JavaScript de pagina op. Vergelijk dit met Next.js, dat volledig gerenderde HTML vanaf de server stuurt: de browser toont content onmiddellijk terwijl JavaScript op de achtergrond laadt.
Daarom voelt uw Framer-site snel aan op uw laptop maar scoort die slecht op PageSpeed. De test simuleert een echt mobiel apparaat op een echte mobiele verbinding, niet een MacBook op glasvezel.
Animatie-overhead
Het animatiesysteem van Framer is krachtig maar kostbaar. Elke scroll-getriggerde animatie, elk hover-effect en elke paginatransitie verhogen de JavaScript-uitvoeringskosten. Animaties die vloeiend aanvoelen op desktop kunnen zichtbare haperingen veroorzaken op mobiele apparaten met minder rekenkracht.
Beperkte beeldoptimalisatie
Framer biedt basisbeeldoptimalisatie, maar er is geen controle over formaten, kwaliteitsinstellingen of responsieve formaatstrategieën. De Image-component van Next.js levert automatisch WebP/AVIF in de juiste afmetingen voor elk apparaat, met lazy loading en blur-up placeholders. Het verschil in beeldgrootte alleen al kan 50-80% zijn.
Wat u binnen Framer kunt doen
Als u op Framer wilt blijven, zijn er zinvolle verbeteringen mogelijk:
- Verminder het aantal animaties, want elke animatie kost prestaties
- Comprimeer afbeeldingen voor het uploaden in plaats van te vertrouwen op Framer's optimalisatie
- Minimaliseer aangepaste code-overrides en ingebedde scripts
- Verwijder ongebruikte componenten en secties
- Vermijd diep geneste componentstructuren
Realistisch gezien kunnen deze optimalisaties de score met 10-15 punten verbeteren. Bij een score van 45 komt u misschien op 55-60. Dat blijft onder Google's drempel voor "goede" prestaties.
De zakelijke kosten
Google gebruikt Core Web Vitals als rankingsignaal. Een trage mobiele ervaring betekent lagere zoekposities. Naast SEO verlaat 53% van de mobiele bezoekers een site die langer dan 3 seconden laadt (Google-data). Als de LCP van uw Framer-site 4 seconden of meer is, verliest u bezoekers voordat ze uw content zien.
Voor sites die afhankelijk zijn van organisch verkeer of betaalde advertentieconversies heeft slechte prestatie direct invloed op de omzet. Elke 100ms extra laadtijd verlaagt de conversieratio met ongeveer 1%.
Het alternatief
Een Next.js-rebuild behoudt het ontwerp terwijl de onderliggende prestatieproblemen worden opgelost. De visuele output blijft gelijk: dezelfde lay-out, dezelfde animaties, dezelfde merkidentiteit. Het leveringsmechanisme verandert van client-gerenderd JavaScript naar server-gerenderde HTML met geoptimaliseerde assets.
Het resultaat is in webvise-migratieprojecten doorgaans een sprong van 45-65 op mobiele PageSpeed naar 92-99. Hetzelfde ontwerp, merkbaar betere prestaties. Betere rankings, lagere bouncepercentages, hogere conversies.
Als uw Framer-site een zakelijk hulpmiddel is en geen portfoliostuk, verdient prestatie prioriteit. Voer uw site door PageSpeed Insights op mobiel en bekijk waar u staat. De cijfers laten zien of optimalisatie binnen het platform voldoende is of dat de architectuur van Framer de grenzen bepaalt van wat haalbaar is voor uw situatie.