Edge SEO to praktyka uruchamiania logiki SEO bezpośrednio na warstwie CDN, czyli w środowisku takim jak Cloudflare Workers, Vercel Edge Functions czy Netlify Edge. W 2026 roku nie jest to już niszowy eksperyment, tylko realna alternatywa dla wdrożeń, które wymagają natychmiastowych zmian w technicznym SEO bez ruszania monolitycznego CMS-a. W tym przewodniku pokazujemy, jak działa edge seo, kiedy ma sens, jak wdrożyć je krok po kroku oraz jakie metryki naprawdę warto mierzyć.
Czym jest edge seo
Edge SEO to wykonywanie kodu SEO (przepisywanie nagłówków, modyfikacja HTML, A/B testy meta tagów, hreflang, redirecty 301, dynamiczne sitemap.xml) na serwerach brzegowych dostawcy CDN, fizycznie blisko użytkownika i robota wyszukiwarki. Zamiast czekać na deploy monolitu (np. WordPress, Magento, Shopware), inżynier SEO wgrywa tzw. worker, czyli niewielki skrypt JavaScript lub TypeScript, który przechwytuje request i zwraca zmodyfikowaną odpowiedź.
Według dokumentacji Cloudflare Workers jeden worker uruchamia się w czasie rzędu pojedynczych milisekund, a globalna sieć obejmuje 300+ lokalizacji. Vercel Edge Functions oraz Netlify Edge stoją na podobnej architekturze (Deno + V8 isolates), więc paradygmat jest spójny niezależnie od dostawcy.
W praktyce edge seo nadaje się do trzech klas problemów: dynamicznych modyfikacji HTML (np. wstrzyknięcie schemy JSON-LD, podmiana title), inteligentnych przekierowań i hreflang oraz generowania artefaktów (sitemap, robots.txt, llms.txt) z danych zewnętrznych. Dla bardziej zaawansowanego renderingu warto zestawić edge seo z technikami opisanymi w naszym tekście o JavaScript SEO 2026: rendering, hydration, krytyczne bottlenecki, bo edge to często odpowiedź na ograniczenia SSR po stronie aplikacji.
Edge SEO vs reverse proxy SEO
Reverse proxy SEO (Distilled ODN, SearchPilot) historycznie wymagał osobnego, dedykowanego proxy. Edge SEO oparty o Workers redukuje to do kodu w repozytorium oraz konfiguracji DNS u istniejącego CDN. Koszt wejścia spada z dziesiątek tysięcy złotych miesięcznie do kilkudziesięciu dolarów na planie Cloudflare Workers Paid.
Krótka historia: skąd się to wzięło
Pierwsze publiczne wdrożenia edge seo (rozumianego jako Cloudflare Workers wykorzystywane do celów SEO) datuje się na lata 2018–2019, gdy Dan Taylor i Stefan Lau pokazali serię prezentacji o tym, jak workerzy potrafią rozwiązać problemy, których nie da się rozwiązać po stronie aplikacji w rozsądnym czasie. Do 2022 roku ekosystem dojrzał na tyle, że Cloudflare zaczął oferować KV (key-value storage), Durable Objects oraz R2, dzięki czemu workerzy z prostych transformatorów stali się pełnoprawnymi aplikacjami brzegowymi. W 2024 i 2025 roku Vercel oraz Netlify dorzuciły własne implementacje, a frameworki typu Next.js, Astro, Remix i Nuxt zintegrowały middleware brzegowe w sposób natywny. W 2026 roku edge seo wszedł w fazę dojrzałości: jest już opisywany w oficjalnych dokumentacjach Google, omawiany w głównych ścieżkach SEO BrightonSEO i SMX Advanced, a większość headless commerce wdraża go jako standardowy element architektury.
Kiedy edge seo NIE ma sensu
Każda warstwa abstrakcji ma koszt. Edge seo nie powinien być pierwszą inwestycją w sytuacjach, w których brakuje fundamentalnych elementów: poprawnej struktury URL, sensownej taksonomii, sitemap, robots.txt czy szybkiego serwera origin. Worker nie ratuje serwisu, który nie ma pomysłu na content. Edge seo skaluje istniejące dobre praktyki, nie zastępuje ich. Drugi przypadek, w którym warto się wstrzymać, to bardzo mały serwis (poniżej 500 URL-i) z prostą, monolityczną aplikacją, którą da się szybko deployować. Wprowadzanie workerów w takim środowisku to nadinżynieria.
Najważniejsze zasady i framework
Zanim napiszesz pierwszy worker, ułóż framework decyzyjny. Pominięcie tego kroku najczęściej kończy się chaosem trzech zespołów pracujących niezależnie nad tym samym nagłówkiem HTTP.
Trzy warstwy zmian
- Warstwa źródłowa. Wszystko, co da się poprawić w kodzie aplikacji (CMS, motyw, headless front), powinno trafić tam. To jest warstwa kanoniczna.
- Warstwa edge. Trafia tu to, czego nie da się szybko zmienić w źródle (legacy CMS, długi cykl deploymentu, brak zasobów), oraz zmiany z natury globalne (przekierowania, geo-routing, A/B testy).
- Warstwa runtime klienta. Ostatnia deska ratunku. Manipulacja DOM po stronie przeglądarki obarczona jest opóźnieniem renderowania i ryzykiem niewidoczności dla cache CDN czy starszych crawlerów.
Pięć zasad bezpiecznego wdrożenia
- Idempotencja. Każdy worker powinien być bezpieczny do ponownego uruchomienia na tym samym requeście. Nigdy nie zapisuj globalnego stanu wewnątrz handlera.
- Wersjonowanie. Trzymaj kod workerów w git, traktuj jak produkcyjną aplikację: PR review, testy, environment dev/staging/prod.
- Granularność feature flag. Dla każdej reguły edge dodaj flagę (np. KV lub Workers Secrets), pozwalającą wyłączyć ją w 30 sekund bez deployu.
- Obserwowalność. Loguj decyzje workera (Logpush, Datadog, Honeycomb). Brak logów = brak debugowania w środę o 23:00.
- Limit czasu. Worker przekraczający 50 ms na p95 jest podejrzany. Workers mają twardy limit CPU (50 ms na free, 30 s wallclock na paid), ale dobre praktyki SEO to 5–15 ms.
Macierz odpowiedzialności
| Zadanie | Warstwa źródłowa | Edge | Klient |
|---|---|---|---|
| Tytuł i meta opis | Tak (kanoniczne) | A/B test, override | Nie |
| Hreflang | Tak, jeśli stabilne | Tak, jeśli zmienne (geo) | Nie |
| Schema JSON-LD | Tak (preferowane) | Tak, jeśli źródło bez wsparcia | Tylko jako fallback |
| Redirecty 301 | Tak (regex .htaccess) | Tak (lepsza skala) | Nie |
| Sitemap dynamic | Tak (cron + cache) | Tak (live z bazy) | Nie |
| Bot detection | Tylko serwer | Tak (lepsza precyzja) | Nie |
Jak to wdrożyć krok po kroku
Najprostsza ścieżka wejścia w edge seo prowadzi przez Cloudflare Workers, ponieważ nie wymaga zmiany hostingu. Aplikacja zostaje tam, gdzie była; zmienia się tylko warstwa DNS (A/AAAA lub CNAME wskazujące na Cloudflare) oraz routing workerów na konkretne wzorce URL.
Krok 1: Audyt i lista priorytetów
Wyciągnij z Search Console listę 20 najczęstszych problemów technicznych. Posortuj po liczbie zaindeksowanych URL-i objętych problemem. Jeśli reguła dotyczy mniej niż 200 URL-i lub pojedynczego template, prawdopodobnie nie zasługuje na worker. Edge seo opłaca się tam, gdzie efekt skaluje się na tysiące adresów.
Krok 2: Konfiguracja Cloudflare Workers
Załóż konto na cloudflare.com, dodaj domenę (Free lub Paid plan), poczekaj na propagację DNS. Następnie zainstaluj wrangler CLI:
npm install -g wrangler
wrangler login
wrangler init seo-workersKrok 3: Pierwszy worker, czyli przepisanie title
Poniższy przykład używa HTMLRewriter, natywnego API Cloudflare do strumieniowego parsowania HTML bez konieczności wczytywania całego dokumentu do pamięci.
export default {
async fetch(request, env) {
const response = await fetch(request);
const url = new URL(request.url);
if (!response.headers.get("content-type")?.includes("text/html")) {
return response;
}
return new HTMLRewriter()
.on("title", {
text(text) {
if (url.pathname.startsWith("/kategoria/")) {
text.replace(text.text + " | sklep online 2026", { html: false });
}
}
})
.transform(response);
}
};Worker przepuszcza ruch normalnie, ale dla URL-i kategorii dopisuje sufiks do tagu title. To prosty, bezpieczny scenariusz wejściowy. Wdrożenie: wrangler deploy i przypisanie route example.com/kategoria/*.
Krok 4: Hreflang dla geo-routingu
Jeśli serwujesz różne wersje językowe pod tym samym hostem, edge potrafi dynamicznie wstrzyknąć kompletny zestaw <link rel="alternate" hreflang="..."> bez modyfikowania szablonu w aplikacji. Worker odczytuje cookie locale oraz nagłówek cf-ipcountry, a następnie wkleja blok hreflang w <head>.
Krok 5: Sitemap z live source of truth
Klasyczne sitemapy generowane raz na dobę nie nadążają za sklepami z 500 tysiącami SKU. Worker łączy się z endpointem produktowym (np. /api/products?modified_since=...) i serializuje XML on-demand z cachem 5–10 minut na poziomie KV. Efekt: sitemap zawsze świeża, koszt poniżej 5 USD miesięcznie.
Krok 6: Vercel Edge Middleware (alternatywa)
Jeśli front jest już na Next.js + Vercel, użyj plików middleware.ts w katalogu głównym projektu. Składnia jest podobna do Workers, ale uruchamiana automatycznie przy każdym deployu.
import { NextResponse } from "next/server";
export const config = { matcher: ["/blog/:path*"] };
export function middleware(req) {
const res = NextResponse.next();
res.headers.set("x-seo-experiment", "title-v2");
return res;
}Krok 7: Testy A/B na meta tagach
Worker dzieli ruch w stosunku 50/50 (np. po hashu URL-a), zapisuje wybór wariantu w cookie i raportuje konwersje do BigQuery przez Logpush. Po 14 dniach wystarczy SQL, by zdecydować, który wariant title generuje wyższy CTR w Search Console. To jest moment, w którym edge seo zaczyna zarabiać na siebie kilkukrotnie.
export default {
async fetch(request, env) {
const variant = hash(new URL(request.url).pathname) % 2 === 0 ? "A" : "B";
const response = await fetch(request);
if (!response.headers.get("content-type")?.includes("text/html")) {
return response;
}
return new HTMLRewriter()
.on("title", {
text(text) {
if (variant === "B") {
text.replace(text.text.replace("kup", "zamów"), { html: false });
}
}
})
.on("head", {
element(el) {
el.append(`<meta name="x-experiment" content="${variant}">`, { html: true });
}
})
.transform(response);
}
};Krok 8: Wstrzykiwanie schemy JSON-LD
Jednym z najbardziej dochodowych zastosowań edge seo jest dodawanie struktur danych do stron, których CMS nie wspiera natywnie. Klasyczny przypadek: legacy serwis B2B na własnym CMS-ie z 2014 roku, w którym dodanie pola do bazy danych zajmuje deweloperowi tydzień. Worker w 30 linijkach generuje kompletną schemę FAQPage, BreadcrumbList lub Product na podstawie istniejącej zawartości HTML. Zysk: rich results w SERP, wyższy CTR i widoczność w panelach AI Overviews oraz w odpowiedziach generatywnych. Koszt: jeden deploy, brak konieczności ruszania monolitu.
Krok 9: llms.txt i AI-friendly artefakty
W 2026 roku coraz więcej serwisów dorzuca plik /llms.txt (analogiczny do robots.txt, lecz ukierunkowany na crawlery LLM) oraz wzbogacone wersje markdown najważniejszych podstron. Worker generuje je dynamicznie z bazy posts, dzięki czemu nie trzeba tworzyć osobnego pipeline build-time. Dla typowego sklepu to oznacza, że ChatGPT, Claude i Perplexity dostają zawsze najświeższą wersję treści produktowych bez konieczności scrapingu pełnego HTML.
Najczęstsze błędy i pułapki
Zespoły wchodzące w edge seo popełniają kilka powtarzalnych błędów, które potrafią zniweczyć efekt całego wdrożenia.
Cloaking, czyli różne treści dla bota i użytkownika
Worker, który odróżnia Googlebota po user-agencie i serwuje mu zoptymalizowaną wersję, łamie wytyczne Google. Google Search Central jednoznacznie traktuje to jako cloaking. Edge SEO zawsze powinno pokazywać tę samą treść użytkownikom i robotom, modyfikacje mogą dotyczyć tylko warstwy meta lub strukturalnej (np. sitemap).
Brak invalidacji cache
Cloudflare cachuje odpowiedzi na poziomie krawędzi. Jeśli worker generuje dynamiczny title, ale CDN cachuje cały HTML na 24 godziny, zmiana stanie się widoczna dopiero po wygaśnięciu cache. Rozwiązanie: cf.cacheTtl, cache.put z własnym kluczem oraz świadomy Cache-Control w odpowiedzi workera.
Pętle redirectów
Reguła jeśli URL kończy się na slash, przekieruj bez slasha w połączeniu z konkurencyjną regułą w .htaccess potrafi stworzyć pętlę 301 zauważalną dopiero po godzinach. Zawsze testuj redirecty workerem curl -IL przed przekierowaniem na produkcję.
Manipulacja headerów wpływających na cache
Dodawanie Vary: User-Agent bez zrozumienia konsekwencji powoduje, że CDN przestaje cachować cokolwiek, co dla dużego serwisu oznacza realny wzrost kosztów oraz spowolnienie LCP.
Workerzy bez observability
Każdy zespół, który wpadł w edge seo bez Logpush, Datadog albo własnego loggera w KV, doświadczył sytuacji niewytłumaczalnego spadku w Search Console. Bez logów debugowanie reguły działającej globalnie 18 godzin dziennie jest po prostu niemożliwe.
Mieszanie warstw, czyli ten sam fix w trzech miejscach
Drobny refactor w aplikacji powtórzony niezależnie w workerze i w GTM. Po pół roku nikt nie wie, która warstwa generuje finalny tag canonical. Lekarstwo: macierz odpowiedzialności zaakceptowana przez devów, SEO i marketing, oraz kwartalny audyt warstw.
Brak rollback planu
Worker, który psuje produkcyjne SEO o 3 nad ranem, musi mieć wyraźnie określoną ścieżkę rollback. Najczęstszy wzorzec: dwa worker scripts w środowisku Cloudflare (canary i stable), pre-deploy hook publikujący najpierw na canary, ręczna lub automatyczna promocja po 30 minutach jeśli metryki techniczne nie spadły. Brak takiego pipeline kończy się tym, że senior SEO o 3:14 w nocy szuka wczorajszej wersji workera w git log, zamiast spać.
Worker, który zabija WebSockety i streaming
HTMLRewriter buforuje odpowiedź, by ją parsować. Jeśli reguła obejmuje endpointy SSE (Server-Sent Events), WebSockety lub HTTP/2 push, klient zobaczy nagle opóźnienia rzędu sekund. Lekarstwo: warunkowe stosowanie HTMLRewriter wyłącznie dla text/html oraz wykluczenie ścieżek typu /api/stream/* już na poziomie route Cloudflare.
Niezgodność z Core Web Vitals
Logpush bez próbkowania potrafi dorzucać do każdego requestu kilkadziesiąt milisekund I/O. Dla serwisów z TTFB w okolicach 200 ms może to oznaczać degradację LCP o 10–15%. Włącz sampling (np. 10% requestów) w trybie produkcyjnym i zostaw pełny logging tylko w środowisku staging.
Pominięcie kosztu zimnego startu
V8 isolates Cloudflare są generalnie szybkie, ale pierwsze wywołanie nowo zdeployowanego workera w danej lokalizacji ma narzut rzędu 5–20 ms. Dla serwisów krytycznych (sklepy, fintech) warto rozważyć „warm-up”, czyli okresowe pingi z monitoringu, które trzymają isolates aktywne w głównych regionach.
Mierzenie efektów i KPI
Edge SEO bez metryk to kosztowna zabawka. Aby uzasadnić budżet i utrzymać priorytet u CTO, warto pilnować trzech grup wskaźników.
KPI techniczne
- p50/p95 latencji workera w ms (cel: 5–15 ms, alarm powyżej 30 ms).
- Liczba błędów 5xx generowanych przez worker (cel: poniżej 0,01% requestów).
- Cache hit ratio dla URL-i objętych workerem (cel: powyżej 80% po pierwszym tygodniu).
- CPU time na request (Cloudflare bilijuje czas CPU, więc każda mikrosekunda się liczy).
KPI SEO
- Crawl budget mierzony w Search Console: liczba żądań Googlebota dziennie i status code.
- Indeksacja URL-i objętych workerem (raport Strony w GSC, sekcja Zaindeksowane vs Wykryte ale nie zaindeksowane).
- CTR w wynikach wyszukiwania dla URL-i z eksperymentem A/B.
- Średnia pozycja kluczowych zapytań przed i po wdrożeniu, w oknie 28 dni.
- Core Web Vitals, szczególnie LCP, ponieważ worker dodaje narzut do TTFB.
KPI biznesowe
- Ruch organiczny na URL-ach pod regułą edge (porównanie YoY i MoM).
- Konwersja organiczna, np. zamówienia, leady, rejestracje.
- Koszt operacyjny: rachunek Cloudflare/Vercel + roboczogodziny zespołu.
- Time-to-fix: średni czas od zgłoszenia problemu SEO do jego rozwiązania (edge powinien skrócić go z dni do godzin).
Dashboard w 30 minut
Połącz Logpush Cloudflare z BigQuery, podepnij Looker Studio i zbuduj jeden dashboard z trzema sekcjami: technika (latencja, errors), SEO (crawl, indeksacja, CTR), biznes (ruch, konwersja). Z takiego dashboardu CTO i CMO zobaczą efekt na jednej stronie, co maksymalizuje szansę na utrzymanie budżetu w kolejnym kwartale.
Studium przypadku: sklep z elektroniką, 6 miesięcy edge seo
Średniej wielkości sklep z elektroniką (ok. 80 tysięcy SKU, 2,3 mln sesji organicznych miesięcznie) wdrożył edge seo w styczniu 2026 roku. Zakres: dynamiczne tytuły kategorii, A/B testy meta opisów, wstrzykiwanie schemy Product oraz BreadcrumbList, sitemap on-demand z live source of truth. Wyniki po sześciu miesiącach: wzrost CTR z SERP o 14%, wzrost zaindeksowanych URL-i o 9%, spadek time-to-fix dla problemów technicznych z 7 dni do 4 godzin. Koszt operacyjny: 38 USD miesięcznie za Workers Paid plus 6 godzin pracy senior SEO inżyniera tygodniowo. ROI policzony jako wartość dodatkowego ruchu organicznego: ok. 18-krotny zwrot z inwestycji w pierwszym kwartale po wdrożeniu.
Statistical significance w testach A/B na meta tagach
Eksperymenty na meta opisach wymagają większej próbki niż klasyczne testy konwersji, bo CTR organiczny jest niższy niż konwersja sklepowa, a wariancja wyższa. Dla URL-i z miesięcznym ruchem 5 tysięcy wyświetleń w SERP minimalna długość testu to 21–28 dni. Krótsze okna prowadzą do fałszywie pozytywnych wniosków. W praktyce warto stosować poprawkę Bonferroniego, jeśli równolegle testujesz meta tagi na kilku grupach URL-i.
Zaawansowane wzorce: KV, Durable Objects, R2
Po opanowaniu podstawowych workerów warto sięgnąć po pełniejszy zestaw narzędzi Cloudflare. Każde z nich rozwiązuje inną klasę problemów SEO i razem tworzy ekosystem zdolny obsłużyć poważne wdrożenia.
KV: szybki cache decyzji SEO
Workers KV to globalnie replikowane key-value storage z odczytem rzędu pojedynczych milisekund. Idealne miejsce na: mapy redirectów (klucz: stary URL, wartość: nowy URL + kod 301/302), feature flagi reguł SEO, słownik canonicals dla URL-i z parametrami, listę bots, którym pozwalamy na różne ścieżki. Limit pojedynczego pliku to 25 MiB, co dla większości map wystarcza z zapasem. Zapis ma propagację rzędu 60 sekund, więc KV nie nadaje się do real-time, ale dla SEO ten kompromis jest neutralny.
Durable Objects: state per-URL
Durable Objects pozwalają trzymać stan przypisany do konkretnego klucza (np. URL-a) w jednym, globalnie spójnym miejscu. To narzędzie do liczenia, dystrybucji ruchu w testach A/B z gwarancją równego split, lub do agregacji metryk per-template w czasie rzeczywistym. Koszt jest wyższy niż KV, ale spójność transakcyjna otwiera scenariusze niemożliwe na KV.
R2: hosting artefaktów SEO bez egress fee
R2 to S3-compatible object storage Cloudflare bez opłat za egress, świetne miejsce na duże sitemap (rozbite na pliki po 50 tysięcy URL-i każdy zgodnie ze specyfikacją sitemaps.org), feed RSS/JSON-Feed dla sekcji bloga, wygenerowane wersje OG image dla artykułów. Worker może serwować je z dodatkowymi nagłówkami cache lub przepisanymi linkami, bez konieczności trzymania kopii w aplikacji.
Edge SEO w architekturze klastra tematycznego
Edge SEO świetnie współpracuje z innymi obszarami strategii. Jeśli budujesz autorytet tematyczny, sprawdź nasz przewodnik Topical authority pod LLM: jak budować klastry tematyczne 2026: workerzy mogą automatycznie wstrzykiwać linki kontekstowe między artykułami klastra. Dla biznesów lokalnych ważnym uzupełnieniem jest Local SEO Polska 2026: PFG, opinie, lokalne entity, gdzie edge potrafi serwować zoptymalizowane bloki LocalBusiness w zależności od regionu odwiedzającego. A jeśli równolegle prowadzisz kampanie płatne, warto skonfrontować to z naszym tekstem o Google Performance Max 2026: feed pod AI, asset coverage, scripts, ponieważ te same dane produktowe zasilają zarówno feed PMax, jak i sitemap generowaną na edge.
Checklist wdrożeniowy edge seo na 2026 rok
Krótka lista kontrolna do wykorzystania jako brief dla zespołu przed startem projektu.
- Zinwentaryzuj problemy techniczne SEO ostatnich 12 miesięcy: które wymagały deployu monolitu, które trwały dłużej niż 5 dni, które dotyczyły powyżej 1000 URL-i. To Twoja krótka lista kandydatów na workera.
- Wybierz CDN: Cloudflare (najszerszy ekosystem), Vercel (jeśli front już tam stoi), Netlify (statyka + funkcje brzegowe). Decyzja oparta o istniejący stos, nie o trendy.
- Załóż repo
seo-workers, w pierwszym commicie konfiguracja CI/CD, w drugim szablon workera „no-op” przepuszczający ruch bez zmian. Taka baza pozwala dodawać reguły iteracyjnie. - Włącz observability od razu: Logpush + BigQuery + Looker, nawet jeśli pierwszy worker robi tylko jedną prostą rzecz. Brak observability to dług, który trudno spłacić później.
- Zdefiniuj SLO: latencja p95, error rate, cache hit ratio. Dopiero potem pisz pierwszy production workflow.
- Ustal kwartalny audyt warstw: co siedzi w aplikacji, co na edge, co w GTM. Każdy duplikat usuń.
- Zaplanuj rollback: pre-deploy hook na canary route, automatyczna promocja po N minut przy zielonych metrykach.
- Dokumentuj decyzje (ADR, czyli Architecture Decision Records). Za rok nikt nie będzie pamiętał, dlaczego worker dla
/szukajzwraca 410 zamiast 404.
FAQ
Czy edge seo to to samo co reverse proxy SEO?
Nie, choć cele są podobne. Reverse proxy SEO (np. Distilled ODN) wymagało osobnej infrastruktury proxy. Edge SEO uruchamia logikę bezpośrednio na CDN, który już obsługuje ruch. Koszt wejścia jest dziesiątki razy niższy, a wdrożenie liczone w godzinach, nie w tygodniach.
Czy worker spowalnia stronę?
Dobrze napisany worker (5–15 ms na request) jest praktycznie niezauważalny i często szybszy niż natywna logika aplikacji, ponieważ działa na lokalizacji najbliższej użytkownikowi. Źle napisany worker (np. odpytujący zewnętrzne API synchronicznie) potrafi dorzucić 200–500 ms do TTFB.
Czy Google traktuje treść z edge tak samo jak z serwera źródłowego?
Tak, dopóki worker zwraca tę samą zawartość użytkownikom i robotom. Google nie rozróżnia, czy HTML powstał w PHP, w Node.js czy w Cloudflare Worker. Liczy się finalna odpowiedź HTTP.
Cloudflare Workers, Vercel Edge czy Netlify Edge?
Cloudflare Workers wygrywa w scenariuszach, w których aplikacja jest na innym hostingu i potrzebny jest globalny zasięg + niska cena. Vercel Edge naturalnie pasuje do projektów Next.js. Netlify Edge stoi na podobnej technologii, dobrze dogadanej z hostingiem statycznym Netlify. Wybór najczęściej dyktuje istniejący stos.
Czy potrzebuję plana Cloudflare Enterprise?
Nie. Workers Paid (5 USD/miesiąc) starcza dla większości średnich serwisów (10 mln requestów + 30 s CPU/dzień). Enterprise jest potrzebny dopiero przy bardzo dużych wolumenach lub specyficznych wymaganiach SLA i compliance.
Jak debugować workera, który raz na 1000 requestów odpowiada 500?
Włącz Logpush albo Tail Logs (wrangler tail), ustaw structured logs z polami request_id, url, route, cf_ray. Dorzuć Sentry przez ich edge SDK. Bez observability debugowanie reguły działającej w 300 lokalizacjach jest niewykonalne.