Piękna strona zbudowana w Framer. Animacje działają płynnie w edytorze, projekt wygląda dopracowanie, a całość sprawia wrażenie szybkiej na MacBooku Pro. Po uruchomieniu testu PageSpeed na ekranie pojawia się wynik 45.
To częsty problem. Strony Framer regularnie nie spełniają wymagań Google Core Web Vitals, szczególnie na urządzeniach mobilnych. Poniżej wyjaśnienie, dlaczego tak się dzieje, oraz dostępne opcje działania.
Liczby dotyczące wydajności
W ciągu ostatniego roku przebadano dziesiątki firmowych stron Framer. Wzorzec jest spójny:
| Metryka | Średnia Framer | Próg "dobry" Google | Średnia Next.js |
|---|---|---|---|
| Mobilny wynik PageSpeed | 42-65 | 90+ | 92-99 |
| Largest Contentful Paint | 3,2-5,8s | Poniżej 2,5s | 0,8-1,5s |
| Total Blocking Time | 400-1200ms | Poniżej 200ms | 10-80ms |
| Cumulative Layout Shift | 0,05-0,25 | Poniżej 0,1 | 0-0,02 |
To typowe zakresy dla firmowych stron Framer z animacjami, treścią CMS i niestandardowymi komponentami. Prostsze witryny mogą wypadać lepiej, jednak złożoność konsekwentnie obniża wyniki.
Dlaczego strony Framer bywają wolne
Ciężka paczka JavaScript
Framer dostarcza duże środowisko uruchomieniowe JavaScript na każdą stronę. Zasila ono silnik animacji, renderowanie CMS i system komponentów. Nawet prosta strona docelowa z minimalną treścią ładuje 200-400KB JavaScript zanim pojawi się właściwa zawartość.
Na średniej klasy telefonie z Androidem podłączonym przez 4G parsowanie i wykonanie tego kodu zajmuje od 1 do 3 sekund. To zanim załadują się obrazy, zanim wyrenderują się czcionki, zanim użytkownik zobaczy cokolwiek użytecznego.
Renderowanie po stronie klienta
Framer renderuje strony głównie po stronie klienta. Przeglądarka pobiera HTML, następnie JavaScript, a dopiero potem JavaScript buduje stronę. Next.js wysyła w pełni wyrenderowany HTML z serwera, dzięki czemu przeglądarka wyświetla treść natychmiast, a JavaScript ładuje się w tle.
Stąd strona Framer sprawia wrażenie szybkiej na laptopie, a uzyskuje słabe wyniki w PageSpeed. Test symuluje rzeczywiste urządzenie mobilne z rzeczywistym połączeniem mobilnym, nie MacBooka na łączu światłowodowym.
Narzut animacji
System animacji Framer jest rozbudowany, ale kosztowny obliczeniowo. Każda animacja wyzwalana przewijaniem, efekt hover i przejście między stronami zwiększa koszt wykonywania JavaScript. Animacje płynne na komputerze stacjonarnym mogą powodować widoczne zacinanie na urządzeniach mobilnych z mniejszą mocą obliczeniową.
Ograniczona optymalizacja obrazów
Framer obsługuje podstawową optymalizację obrazów, ale bez kontroli nad formatami, ustawieniami jakości ani strategiami responsywnego wymiarowania. Komponent Image w Next.js automatycznie serwuje WebP/AVIF w odpowiednich wymiarach dla każdego urządzenia, z lazy loading i rozmytymi placeholderami. Sama różnica w rozmiarze plików graficznych sięga 50-80%.
Co można zrobić w ramach Framer
Dla tych, którzy chcą pozostać na Framer, dostępne są konkretne usprawnienia:
- Ograniczyć liczbę animacji, każda z nich kosztuje wydajność
- Kompresować obrazy przed przesłaniem zamiast polegać na optymalizacji Framer
- Minimalizować niestandardowe code overrides i osadzone skrypty
- Usunąć nieużywane komponenty i sekcje
- Unikać głęboko zagnieżdżonych struktur komponentów
Realistycznie te optymalizacje mogą poprawić wynik o 10-15 punktów. Przy wyjściowym wyniku 45 można osiągnąć poziom 55-60, co nadal plasuje się poniżej progu Google dla "dobrej" wydajności.
Koszt biznesowy
Google używa Core Web Vitals jako sygnału rankingowego. Słabe wyniki mobilne przekładają się na niższe pozycje w wyszukiwarce. Poza SEO, 53% mobilnych użytkowników opuszcza strony, które ładują się dłużej niż 3 sekundy (dane Google). Gdy LCP strony na Framer przekracza 4 sekundy, odwiedzający odchodzą, zanim zobaczą jakąkolwiek treść.
Strony zależne od ruchu organicznego lub konwersji z płatnych kampanii odczuwają wpływ słabej wydajności bezpośrednio na wynikach finansowych. Każde dodatkowe 100ms czasu ładowania obniża współczynnik konwersji o około 1%.
Alternatywa
Przebudowa na Next.js zachowuje projekt, eliminując jednocześnie podstawowe problemy z wydajnością. Efekt wizualny pozostaje identyczny: ten sam układ, te same animacje, ta sama tożsamość marki. Mechanizm dostarczania zmienia się z renderowanego po stronie klienta JavaScript na renderowany po stronie serwera HTML ze zoptymalizowanymi zasobami.
W projektach migracyjnych realizowanych przez webvise wynik mobilny PageSpeed skacze regularnie z poziomu 45-65 do 92-99. Ten sam projekt, mierzalnie lepsza wydajność. Wyższe pozycje, niższy współczynnik odrzuceń, wyższe konwersje.
Jeśli strona Framer pełni rolę narzędzia biznesowego, a nie tylko prezentacji portfolio, wydajność powinna być priorytetem. Wystarczy uruchomić ją w PageSpeed Insights na urządzeniu mobilnym i sprawdzić wynik. Liczby pokażą, czy optymalizacja wewnątrz platformy wystarczy, czy architektura Framer osiągnęła swoje granice w danym zastosowaniu.