“Ale po co mi Cloudflare, skoro Next.js ma Vercela?” - to pytanie słyszę regularnie. Vercel to faktycznie natywne rozwiązanie dla Next.js. Deploy jednym kliknięciem, automatyczne skalowanie, edge functions.
Ale rzeczywistość projektów produkcyjnych bywa bardziej skomplikowana. Na naszym szkoleniu poświęcamy sporo czasu Cloudflare i świadomemu projektowaniu warstwy cache z kilku konkretnych powodów.
Nie każdy projekt może działać na Vercelu
Ogromna liczba aplikacji Next.js nie stoi na Vercelu.
W wielu firmach Next.js działa na własnej infrastrukturze: VM-kach, Kubernetesie, AWS ECS, DigitalOcean Dropletach. Powody są różne - polityka bezpieczeństwa korporacji, wymagania RODO dotyczące lokalizacji danych, koszty przy dużym ruchu, integracja z istniejącą infrastrukturą, lub decyzje architektoniczne podjęte lata temu.
W takich przypadkach Cloudflare staje się warstwą, która daje edge caching. Vercel oferuje to out-of-the-box, ale na gołej VM-ce tego nie ma.
Aplikacja Next.js postawiona na serwerze we Frankfurcie obsłuży użytkownika z Warszawy bez problemu. Ale użytkownik z Nowego Jorku? Z Sydney? Każdy request leci przez pół świata do origin servera.
Cloudflare serwuje zcache’owaną odpowiedź z najbliższego edge node’a. To nie magia, to świadome projektowanie nagłówków cache.
Cache na edge to osobny temat
Niezależnie od tego, czy używasz Vercela, Cloudflare, czy Fastly - mechanizmy cache’owania działają tak samo.
Na szkoleniu nie uczymy “kliknij tutaj, włącz tamto”. Uczymy mechanizmów.
Cache-Control - jak go poprawnie ustawiać, co oznaczają poszczególne dyrektywy, kiedy używać public vs private.
s-maxage - jak oddzielić czas cache’owania na edge od czasu cache’owania w przeglądarce użytkownika. stale-while-revalidate - jak serwować “nieświeżą” odpowiedź podczas odświeżania cache w tle, eliminując opóźnienia dla użytkownika. Personalizacja i cookies - jak rozwiązać problem cache’owania treści dla zalogowanych użytkowników. To produkcyjny problem, który zabija wydajność wielu aplikacji.
Vercel pod spodem też korzysta z tych samych mechanizmów HTTP. Bez ich znajomości nie wykorzystasz w pełni ani Vercela, ani żadnego innego CDN.
“Dawaj deploy na Vercel i z głowy” to podejście, które działa do pierwszego poważnego problemu z wydajnością.
Cloudflare daje narzędzia wykraczające poza cache
CDN to nie tylko cache. Cloudflare oferuje narzędzia, które rozwiązują problemy produkcyjne.
Reguły cache per ścieżka pozwalają ustawić /api/* bez cache’a, /blog/* cache na 24h, /static/* cache na rok. Purging umożliwia natychmiastowe unieważnienie cache po deploymencie lub aktualizacji treści. Workers i Transform Rules pozwalają modyfikować requesty i odpowiedzi na edge, bez dotykania origin servera. WAF i rate limiting chronią przed atakami, botami i nadużyciami, zanim ruch w ogóle dotrze do aplikacji. Smart routing przekierowuje ruch przez najszybsze ścieżki sieciowe.
Te narzędzia w Vercelu częściowo masz (w jego własnej formie), ale ich znajomość przydaje się niezależnie od platformy.
Jak to wygląda w praktyce na szkoleniu
Na szkoleniu robimy to na realnym, self-hostowanym Next.js. Stawiamy projekt na VM (bo tak wygląda masa wdrożeń w rzeczywistości) i dokładamy Cloudflare jako edge layer.
Cel: uczestnik umie osiągnąć dobry TTFB i stabilność niezależnie od tego, czy końcowo wybierze Vercel, czy własną infrastrukturę.
W karierze programisty Next.js spotkasz oba światy. Projekty greenfield na Vercelu i legacy aplikacje na dedykowanych serwerach. W obu przypadkach trzeba wiedzieć, jak wycisnąć z nich maksymalną wydajność.
A to dopiero początek
Do tego dochodzą przypadki, gdzie robi się ciekawie.
Różne typy podstron jako osobne aplikacje Next.js - mikrofrontendy, gdzie strona główna, blog i panel admina to oddzielne deploymenty. Load balancing rozkłada ruch między wieloma instancjami origin servera. Współdzielenie cache między różnymi częściami aplikacji wymaga przemyślanej strategii. Do tego dochodzi wspomaganie LLM-ami przy analizie wzorców ruchu i optymalizacji reguł cache.
Połączenie tych elementów tworzy architekturę, która działa pod obciążeniem, jest odporna na awarie i daje użytkownikom szybkie odpowiedzi niezależnie od ich lokalizacji.
Vercel czy własna infrastruktura?
Vercel dla wielu projektów jest dobrym wyborem i nie ma sensu komplikować sobie życia.
Ale znajomość CDN i mechanizmów cache’owania to kompetencja, która wykracza poza jedną platformę. Pozwala pracować z projektami self-hostowanymi, daje zrozumienie tego, co Vercel robi “pod maską”, umożliwia debugowanie problemów z wydajnością na poziomie HTTP i otwiera drzwi do optymalizacji, które nie są możliwe w “automagicznych” rozwiązaniach.
Dlatego na szkoleniu uczymy obu podejść.
Szkolenie Web Performance
Jeżeli interesuje Cię praktyczna wiedza o Web Performance - Core Web Vitals, wzorce cache’owania, optymalizacja aplikacji Next.js na poziomie architektury - zapraszam na nasze szkolenie. Pracujemy na realnych przypadkach, nie na uproszczonych przykładach z dokumentacji.
Sprawdź agendę: Szkolenie WDI - Web Performance City
Szkolenie rusza 10. lutego! Zostało mało miejsc i czasu na podjęcie decyzji.
