Framer, budowa stron i koszt miejsc w zespole
Framer to narzędzie do składania stron internetowych na płótnie, z hostingiem, prostym systemem treści i mocnym zestawem animacji. Projektujesz, publikujesz i strona działa, bez kroku budowania i bez wdrożenia.
Zanim przejdziemy dalej, jedna rzecz, która myli programistów najczęściej. To narzędzie i biblioteka animacji, która przez lata nazywała się Framer Motion, a dziś nosi nazwę Motion, to dwa różne produkty. Biblioteka jest pakietem do Reacta, który dodajesz do własnego projektu. Narzędzie opisane tutaj to zamknięta platforma, w której strona żyje. Wspólne pochodzenie sprawia, że wyniki wyszukiwania mieszają jedno z drugim.
Do czego to jest dobre
Warto nazwać właściwy przypadek użycia, bo poza nim narzędzie przestaje mieć sens.
Strona firmowa, strona produktu, strona wydarzenia albo lądowanie kampanii. Treść zmienia się rzadko, wygląd ma znaczenie, a osobą wprowadzającą zmiany bywa ktoś z marketingu, nie z zespołu wytwórczego.
Wartość leży w tym, że cały łańcuch od pomysłu do opublikowanej strony mieści się w jednym narzędziu. Nie ma przekazania projektu do wykonania, nie ma rozjazdu między makietą a wynikiem, nie ma czekania na wdrożenie. Osoba projektująca publikuje bezpośrednio.
Poza tym zakresem argumenty słabną. Aplikacja z logowaniem, panel z danymi, sklep z tysiącem produktów albo cokolwiek, gdzie logika jest ważniejsza od wyglądu, wymaga rzeczy, których to narzędzie nie robi, i próba ich obejścia kosztuje więcej niż napisanie tego normalnie.
Cennik i pozycja, która zaskakuje
Płatne plany są dwa. Basic kosztuje 10 USD miesięcznie, Pro 30 USD miesięcznie, obok nich stoi plan darmowy na domenie dostawcy, a największe wdrożenia idą na wycenę indywidualną. Plan Scale został wycofany w czerwcu 2026 roku, więc zestawienia wymieniające trzy plany płatne są nieaktualne.
| Plan | Koszt | Strony | Kolekcje i wpisy | Transfer |
|---|---|---|---|---|
| Free | 0 USD | domena dostawcy | do wypróbowania | 1 GB |
| Basic | 10 USD miesięcznie | 30 | 2 kolekcje, 1000 wpisów | 50 GB |
| Pro | 30 USD miesięcznie | 150, potem 20 USD za 100, maks. 700 | 10 kolekcji, 2500 wpisów, potem 20 USD za 10 000, maks. 40 000 | 100 GB, potem 40 USD za 100 GB, maks. 2 TB |
| Enterprise | wycena indywidualna | limity ustalane | limity ustalane | limity ustalane |
Różnica między planami leży nie tylko w wysokości limitów, ale w tym, co dzieje się po ich przekroczeniu. Na Basicu limity są sztywne, na Pro dokupujesz kolejne porcje stron, wpisów i transferu po stawkach z tabeli, aż do wpisanych w plan sufitów. Kwoty planu rosną dodatkowo razem z wybraną pulą kredytów na funkcje AI, a cennik przelicza je suwakiem po stronie przeglądarki, więc przy większej puli sprawdź stawkę u dostawcy. W cenie planu jest 1000 kredytów miesięcznie na Basicu i 3000 na Pro.
Nieoczywista jest druga pozycja rachunku, czyli ludzie. Właściciel przestrzeni roboczej nic nie kosztuje, osoby z samym podglądem i komentarzem też nie, natomiast każde dodatkowe miejsce edytora to 20 USD miesięcznie, a miejsce ograniczone do systemu treści 10 USD miesięcznie. Obie stawki są jednakowe na Basicu i na Pro. W czerwcu 2026 roku cena pełnego miejsca spadła z 40 do 20 dolarów, więc materiały sprzed tej daty podają dwukrotnie wyższe kwoty.
Praktyczny skutek jest taki, że cena widoczna przy planie nie jest ceną całkowitą, ale też nie każda osoba w zespole ją podnosi. Projektant prowadzący przestrzeń mieści się w cenie planu, osoba sprawdzająca stronę przed publikacją wystarczy jako podgląd i nie kosztuje nic, a osoba dopisująca wpisy to 10 dolarów. Płacisz dopiero za drugą i kolejną osobę z pełnym dostępem do projektu.
Miejsce ograniczone do treści daje dostęp do systemu treści, tłumaczeń i edycji tekstu na stronie, bez możliwości zmiany projektu. To sensowne rozwiązanie przy zespole, w którym kilka osób dopisuje wpisy, a układ projektuje jedna.
Jest jeszcze sufit, o którym łatwo zapomnieć: na Basicu i na Pro prawo edycji może mieć najwyżej dziesięć osób. Większy zespół oznacza wycenę indywidualną, gdzie liczba edytorów nie jest ograniczona.
Rachunek warto policzyć przed decyzją, bo przy zespole z kilkoma osobami projektującymi koszt miejsc potrafi przewyższyć koszt planu, a porównanie z alternatywami wychodzi wtedy zupełnie inaczej niż przy zestawianiu samych planów. Kwoty z cennika dotyczą przy tym rozliczenia rocznego, do którego dostawca dokłada darmową domenę.
System treści i jego granice
System treści pozwala zdefiniować kolekcje, dodać do nich pola i wyświetlać wpisy w układzie zaprojektowanym raz. To wystarcza do bloga, listy studiów przypadku, katalogu członków zespołu i podobnych struktur.
Granice ujawniają się przy trzech rzeczach.
Pierwsza to relacje między kolekcjami. Powiązanie artykułów z autorami i kategoriami działa, natomiast przy strukturze z kilkoma poziomami zależności robi się ciasno w porównaniu z systemami przeznaczonymi do treści, na przykład Sanity albo Strapi.
Druga to skala. Kilkaset wpisów obsłuży bez problemu, kilka tysięcy zaczyna być kłopotem przy zarządzaniu, a limity wpisów są zresztą częścią planu, więc rosną razem z rachunkiem.
Trzecia to praca redakcyjna. Wersje robocze, obieg zatwierdzania, tłumaczenia z osobnym stanem dla każdego języka to rzeczy, których zespoły redakcyjne oczekują, a które tutaj są uproszczone.
Wniosek praktyczny: przy treści jako dodatku do strony to jest wystarczające. Przy treści jako głównym produkcie, czyli serwisie z setkami artykułów i redakcją, właściwy jest osobny system treści i strona zbudowana na nim.
Komponenty kodowe, czyli furtka dla programisty
Na płótno można wstawić własny komponent Reacta i to jest funkcja, która czyni to narzędzie interesującym także dla osób piszących kod.
Komponent otrzymuje właściwości ustawiane w interfejsie, więc osoba projektująca może go konfigurować bez dotykania kodu. To jest sensowna droga do rzeczy, których narzędzie nie robi z pudełka: kalkulatora, formularza z nietypową walidacją, licznika pobierającego liczbę z Twojego interfejsu programistycznego.
Kontrolki opisujesz obok komponentu, a narzędzie zamienia je na pola w panelu po prawej stronie.
import { addPropertyControls, ControlType } from "framer"
export function Licznik(props) {
return (
<div>
<strong>{props.wartosc}</strong> {props.etykieta}
</div>
)
}
Licznik.defaultProps = { wartosc: 0, etykieta: "uzytkownikow" }
addPropertyControls(Licznik, {
wartosc: { type: ControlType.Number, title: "Wartosc", min: 0 },
etykieta: { type: ControlType.String, title: "Etykieta" },
})Typów kontrolek jest kilkanaście i obejmują nie tylko liczby i tekst, ale też kolor, obraz z zestawem rozdzielczości, odnośnik czy listę wyboru. Warto sięgać po typ pasujący do danych zamiast wszędzie wstawiać pole tekstowe, bo to od tego zależy, czy osoba projektująca dostanie próbnik koloru, czy będzie wpisywać kod szesnastkowy z pamięci.
Granice są jednak wyraźne i warto je znać wcześniej. Komponent działa w przeglądarce odwiedzającego, więc wszystko, co wymaga sekretu, musi iść przez Twój serwer. Klucz do usługi wpisany w komponent jest publiczny.
Właściwy układ wygląda tak, że komponent nie zna żadnego klucza i pyta wyłącznie Twój własny adres, a ten dokłada uwierzytelnienie po swojej stronie.
import { useEffect, useState } from "react"
export function LicznikZamowien() {
const [liczba, setLiczba] = useState<number | null>(null)
useEffect(() => {
fetch("https://api.twojafirma.pl/publiczne/zamowienia/liczba")
.then((r) => r.json())
.then((d) => setLiczba(d.liczba))
.catch(() => setLiczba(null))
}, [])
return <div>{liczba === null ? "—" : liczba}</div>
}Przy okazji warto obsłużyć nieudane pobranie, bo komponent, który przy błędzie sieci nie renderuje nic, zostawia w układzie dziurę widoczną dla odwiedzającego. Wartość zastępcza kosztuje jedną linię, a ratuje wygląd strony w sytuacji, której nie kontrolujesz.
Druga granica to utrzymanie. Komponent kodowy żyje w projekcie w tej platformie, a nie w Twoim repozytorium, więc wypada z przeglądu kodu, z testów i z historii zmian. Przy jednym prostym komponencie to nie boli, przy pięciu robi się warstwą, której nikt nie pilnuje.
Trzecia dotyczy wydajności. Każdy komponent to kod dosyłany do przeglądarki, a strona reklamowa oceniana jest między innymi po czasie ładowania, więc dokładanie ich bez umiaru podważa jeden z powodów, dla których wybiera się takie narzędzie.
Animacje, czyli powód, dla którego się to wybiera
Animacje są tu wyróżnikiem i warto opisać, na czym polega różnica wobec konkurencji.
Ruch jest tu obywatelem pierwszej kategorii, a nie efektem doklejonym do gotowego układu. Przejścia między stanami komponentu, animacje powiązane z przewijaniem, wejścia elementów przy pojawieniu się w widoku i reakcje na najechanie ustawia się w tym samym miejscu, w którym projektuje się układ.
Zysk praktyczny jest taki, że projektant osiąga wynik, który w innym narzędziu wymagałby przekazania zadania programiście i kilku iteracji uzgadniania. Strona, na której coś się dzieje w reakcji na przewijanie, powstaje w godzinę zamiast w dwa dni.
Pułapka jest równie konkretna i widać ją na wielu stronach zbudowanych tym narzędziem. Łatwość dodawania ruchu prowadzi do stron, na których wszystko wjeżdża, wyjeżdża i reaguje, a odwiedzający zamiast przeczytać ofertę czeka, aż elementy się ułożą. Animacja na pierwszym ekranie opóźnia moment, w którym widać treść, i to jest mierzalna strata.
Rozsądna zasada brzmi: ruch na pierwszym ekranie ograniczaj do minimum albo pomijaj, a niżej używaj go do prowadzenia wzroku, nie do popisu. Warto też sprawdzić stronę z włączonym ustawieniem ograniczającym ruch, bo część odwiedzających je ma i strona zaprojektowana wyłącznie pod animacje wygląda wtedy niekompletnie.
We własnym komponencie to ustawienie odczytasz wprost i zamienisz duży ruch na samo pojawienie się elementu.
import { motion, useReducedMotion } from "motion/react"
export function Karta({ widoczna, children }) {
const mniejRuchu = useReducedMotion()
return (
<motion.div
animate={{
opacity: widoczna ? 1 : 0,
y: widoczna || mniejRuchu ? 0 : 40,
}}
>
{children}
</motion.div>
)
}Zwróć uwagę, że przy włączonym ustawieniu element nadal się pojawia, tylko bez przesunięcia. To jest właściwe rozwiązanie: usunięcie animacji w całości potrafi zostawić układ, w którym nic nie sygnalizuje zmiany stanu, a o to w tym ustawieniu nie chodzi.
Praca zespołowa i publikowanie
Kilka rzeczy operacyjnych, które warto znać przed wdrożeniem tego w firmie.
Publikowanie jest natychmiastowe i na planie Basic nie ma między zmianą a produkcją żadnego etapu zatwierdzania. Osoba z miejscem edytora zmienia stronę na żywo, co jest zaletą przy szybkich poprawkach i ryzykiem przy zespole, w którym ktoś eksperymentuje. Plan Pro dokłada środowisko przejściowe i gałęzie z własnym podglądem, więc dopiero on pozwala zrobić z publikacji krok świadomy, a nie odruchowy. Jeśli zależy Ci na przeglądzie zmian przed wypuszczeniem ich na świat, to jest argument za droższym planem, a nie kwestia ustawienia.
Historia zmian pozwala wrócić do wcześniejszego stanu i to jest zabezpieczenie, które warto przetestować, zanim będzie potrzebne. Sprawdzenie, jak wygląda cofnięcie i ile wersji wstecz sięga, zajmuje kwadrans.
Podgląd dla osób spoza projektu odbywa się przez odnośnik, więc pokazanie wersji roboczej klientowi nie wymaga publikowania. To jest odpowiednik podglądu wdrożenia, do którego przywykły zespoły pracujące na repozytorium.
Domena własna podpina się przez zmianę rekordów, a certyfikat ustawia się sam. Warto natomiast pamiętać, że przekierowania ze starych adresów przy przenoszeniu istniejącej strony trzeba wpisać ręcznie, a ich pominięcie oznacza utratę pozycji w wyszukiwarkach zbudowanych przez lata.
Ostatnia rzecz to podział ról. Jedna osoba projektująca i kilka dopisujących treść przez tańsze miejsca to układ, który działa. Kilka osób projektujących równolegle na tej samej stronie prowadzi do konfliktów, których narzędzie nie rozwiązuje tak dobrze jak system kontroli wersji.
Framer kontra alternatywy
| Rozwiązanie | Kto zmienia treść | Elastyczność | Kiedy wybrać |
|---|---|---|---|
| Framer | Projektant i marketing | Ograniczona do płótna | Strona firmowa z naciskiem na wygląd |
| Next.js z systemem treści | Programista plus redakcja | Pełna | Treść jest produktem, ruch duży |
| v0 plus wdrożenie | Programista | Pełna | Chcesz kodu, który zostaje u Ciebie |
| Gotowy motyw na platformie | Właściciel strony | Mała | Budżet minimalny, standardowa strona |
Pierwszy wiersz wygrywa czasem, a nie możliwościami. Strona, która w drugim wariancie powstaje w dwa tygodnie z udziałem projektanta i programisty, tutaj powstaje w trzy dni z udziałem jednej osoby. Przy stronie firmowej ta różnica jest realna i wymierna.
Drugi wygrywa wtedy, gdy strona ma rosnąć. Kod zostaje u Ciebie, treść mieszka w systemie przeznaczonym do treści, a wydajność i optymalizacja są pod Twoją kontrolą, a nie pod kontrolą dostawcy.
Rzecz, którą warto rozważyć przed decyzją, to wyjście. Strona zbudowana tutaj nie eksportuje się jako projekt do dalszego rozwijania gdzie indziej. Zmiana narzędzia oznacza zbudowanie strony od nowa, więc wybór na trzy lata warto podjąć świadomie, a nie dlatego, że pierwsza wersja powstała szybko.
Wydajność i widoczność w wyszukiwarkach
Dwie rzeczy, o które pytają osoby techniczne, i obie mają konkretną odpowiedź.
Strony są renderowane statycznie i podawane z sieci dostarczania treści, więc podstawa jest w porządku. Tytuły, opisy, adresy przyjazne, mapa strony i dane strukturalne są dostępne w interfejsie i nie wymagają obchodzenia narzędzia.
Ryzyko leży gdzie indziej: w tym, co dokładasz. Strona z pięcioma czcionkami, tłem wideo, animacjami przy przewijaniu i trzema komponentami kodowymi ładuje się wolno niezależnie od tego, jak dobre jest zaplecze. Narzędzie ułatwia dodawanie efektów, więc łatwo przekroczyć granicę, po której wskaźniki jakości ładowania zaczynają szkodzić.
Praktyczna rada jest prosta: zmierz gotową stronę narzędziem badającym wydajność, zanim uznasz ją za skończoną. Największe zyski daje zwykle ograniczenie liczby krojów pisma, zamiana tła wideo na obraz i rezygnacja z animacji przy pierwszym ekranie.
Pomiar da się zrobić z wiersza poleceń, bez zakładania konta gdziekolwiek, i zajmuje minutę.
npx lighthouse https://twojastrona.pl \
--only-categories=performance,seo \
--preset=desktop \
--output=html --output-path=./raport.htmlUruchom to dwa razy: raz w wariancie biurkowym, raz bez tego przełącznika, czyli w emulacji telefonu, bo wyniki potrafią się różnić o kilkadziesiąt punktów. Strona z tłem wideo i trzema krojami pisma wypada przyzwoicie na szybkim łączu i fatalnie na telefonie, a to ten drugi wynik odpowiada temu, jak większość odwiedzających zobaczy stronę.
Typowe błędy
Pierwszy to mylenie tego narzędzia z biblioteką animacji o podobnym rodowodzie. To dwa różne produkty i dokumentacja jednego nie dotyczy drugiego.
Drugi to policzenie kosztu wyłącznie z ceny planu. Miejsca edytora są osobną pozycją i przy kilkuosobowym zespole przewyższają plan.
Trzeci to wybór tego narzędzia do serwisu z setkami artykułów. System treści jest tu uproszczony, a przy treści jako głównym produkcie zaczyna ograniczać po kilku miesiącach.
Czwarty to trzymanie kluczy do usług w komponentach kodowych. Kod działa w przeglądarce odwiedzającego, więc wszystko w nim jest publiczne.
Piąty to dokładanie efektów bez pomiaru. Animacje i tła wideo psują czas ładowania szybciej, niż wynikałoby z wrażenia przy oglądaniu.
Szósty to niesprawdzenie ścieżki wyjścia. Strona nie eksportuje się jako projekt do dalszego rozwijania, więc zmiana narzędzia oznacza budowę od nowa.
FAQ
Czy Framer to to samo co Framer Motion?
Nie. Biblioteka animacji do Reacta, dawniej nazywana Framer Motion, nosi dziś nazwę Motion i jest pakietem dodawanym do własnego projektu. Narzędzie opisane tutaj to zamknięta platforma, w której strona powstaje i mieszka. Wspólne pochodzenie sprawia, że wyniki wyszukiwania je mieszają.
Ile to naprawdę kosztuje?
Plan strony to jedna pozycja: 10 USD miesięcznie na Basicu, 30 USD na Pro. Druga to ludzie: właściciel przestrzeni i osoby z samym podglądem nic nie kosztują, każde dodatkowe miejsce edytora to 20 USD miesięcznie, a miejsce ograniczone do treści 10 USD. Stawkę pełnego miejsca obniżono z 40 dolarów w czerwcu 2026 roku, więc starsze materiały podają dwukrotność.
Czy mogę dodać własny kod?
Tak, przez komponenty w Reakcie wstawiane na płótno, z właściwościami konfigurowanymi w interfejsie. Kod wykonuje się w przeglądarce odwiedzającego, więc nie umieszczaj w nim sekretów, a operacje wymagające klucza kieruj przez własny serwer.
Czy strona będzie dobrze widoczna w wyszukiwarkach?
Podstawa jest w porządku, bo strony są statyczne i podawane z sieci dostarczania treści, a ustawienia tytułów, opisów i danych strukturalnych są dostępne w interfejsie. Ryzykiem jest to, co dokładasz: wiele krojów pisma, tła wideo i animacje psują czas ładowania.
Kiedy wybrać coś innego?
Gdy treść jest produktem, a nie dodatkiem, gdy potrzebujesz logiki wykraczającej poza stronę informacyjną albo gdy zależy Ci na tym, żeby kod został u Ciebie. W tych przypadkach Next.js z osobnym systemem treści daje kontrolę, której tu nie ma.
Dokumentacja stoi na stronie produktu, a warunki planów w cenniku.