EmDash vs WordPress — oczekiwania kontra twarde dane

TL;DR

Zbudowałem dwie identyczne strony — jedną na EmDash + Cloudflare Workers + D1, drugą na ręcznie napisanym motywie WordPress na Hetznerze. Uruchomiłem 4732 zimne pomiary curl-em przez 3,5 dnia. WordPress wygrał 6,4× na czystym czasie przetwarzania serwera (84 ms vs 543 ms). Po wszystkich optymalizacjach EmDasha różnica zeszła do 4,1×. Pełny artykuł z surowymi danymi i repozytoriami żyje na shift64.com — to jest skrót po polsku.

Czego się spodziewałem

Byłem w obozie entuzjastów. Nie dlatego, że “WordPress umarł” — prowadzę praktykę performance’ową na WooCommerce i wiem, jak ten ekosystem dowozi. Byłem entuzjastą w sensie: EmDash to dokładnie to, czego brakuje segmentowi małych firm.

Ogromny kawałek rynku SMB siedzi na WordPressie z jednego powodu: nietechniczny właściciel musi sam edytować ofertę, dane kontaktowe, opisy usług. Nie potrzebuje WooCommerce. Nie potrzebuje 47 wtyczek. Potrzebuje CMS-a.

Co dostaje? Bieżnię utrzymaniową WordPressa — aktualizacje wtyczek, łatki bezpieczeństwa, doroczną panikę “strona jest wolna”.

EmDash na papierze odpowiadał na to dokładnie:

• Astro pod spodem — zero JS-a domyślnie, edge deployment.
• Realny panel admina — klient edytuje treść bez dotykania kodu.
• Cloudflare Workers + D1 — serverless, brak serwera do łatania.
• Błogosławieństwo Cloudflare — narzędzia migracyjne dnia pierwszego.

Jeśli ta kombinacja dowoziłaby ergonomię WordPressa z prędkością Astro, wpadałaby idealnie w światopogląd SHIFT64. Byłem gotowy rekomendować.

Tak bardzo gotowy, że kupiłem domenę emdashcms.pl zanim zrobiłem pierwszy pomiar.

Co pokazały dane

Czas przetwarzania serwera (TTFB minus DNS/TCP/SSL)

Najgorszy pomiar WordPressa (246 ms) jest szybszy niż najlepszy pomiar strony posta na EmDashu (~400 ms). To nie jest margines, który się optymalizuje. To inna kategoria latencji.

WordPress wygrał 13/13 testowanych podstron. Sieć była identyczna — cała różnica to backend.

Cold starty są realne i chodzą za godzinami pracy

Gdy wymusiłem 3-godzinne przerwy między requestami, żeby Workery faktycznie zasypiały:

• Strefa >800 ms jest ekskluzywna dla cold startów. Z 520 requestów warm — 2 przekroczyły 800 ms. Z 260 cold — 50.
• Najgorsza godzina to 10:00 UTC: 745 ms średnio, 35% requestów powyżej 800 ms, max 2,2 s.
• WordPress pokazuje zero efektu cold start. PHP-FPM nigdy nie śpi.

Plan płatny Cloudflare ($5/mc) nie pomógł

Po przejściu z Free na Workers Paid: średnia +72 ms gorsza, % requestów >800 ms wzrósł z 5% do 8,5%. Bottleneck jest poniżej tego, co naprawiają limity CPU.

Niezależny audyt na ślepo

Wysłałem wykresy “Czas pobierania” z Search Console — bez podpisów, bez kontekstu — do Jacka Żmudzińskiego (Head of GEO & SEO w Makolab). Werdykt:

Klasa technologii, z której EmDash jest zbudowany, dostała najwyższą ocenę. Klasa, którą EmDash dowozi, dostała “do wyrzucenia”. Cała historia mieści się w tej luce.

Search Console po tygodniu

Strona WordPressowa — zbudowana w jeden dzień, nigdy nie tknięta ponownie, zgłoszona dzień później — przegania showcase EmDasha na zapytaniu brandowym samego EmDasha.

Co próbowałem z tym zrobić

Po pierwszym benchmarku przeszedłem do kodu i zrobiłem wszystko, co przyszło mi do głowy:

1. server:defer na widget areas — sidebar sam strzelał 7 zapytań D1 na ścieżce krytycznej.
2. Zabicie N+1 nieudokumentowanym batch API — getTermsForEntries, znalezione przez czytanie źródeł.

Wynik: średnia z 542 ms → 322 ms (−41%), P99 z 1094 ms → 424 ms (−61%), max spike z 2196 ms → 745 ms.

Realna wygrana. Nie wystarczająca. WordPress dalej 4,1× szybszy. Pozostałe ~320 ms to podłoga — ~8 sekwencyjnych round-tripów do D1 po ~40 ms każdy. Nie ma na to fixa kodowego. To koszt zadawania bazie na edge’u pytania, które wymaga trzech pytań następczych.

Gdzie EmDash może wygrać — i dlaczego nie u mnie

Wniosek nie brzmi “EmDash jest zły”. Brzmi: jest zły dla case’u, na którym go testowałem — strony niskoruchowe SMB, gdzie Googlebot to połowa dziennego ruchu.

Jeśli odwrócić zmienne — miliony odsłon miesięcznie, ruch całodobowy — wszystko, co tu zmierzyłem jako problem, się zamienia: Worker nigdy nie jest cold, edge cache ma sens, a “brak serwera do łatania” zaczyna się opłacać w realnym budżecie ops. Nie zmierzyłem tego scenariusza i nie zdziwiłbym się, gdyby tam EmDash wyglądał konkurencyjnie.

Ale moim case’em był drugi koniec krzywej. I tam dane są jednoznaczne.

Co to oznacza dla SHIFT64

Zaczynałem ten eksperyment z nadzieją dodania trzeciego narzędzia do stacku. Po 4732 pomiarach — jeszcze nie. Dziś dla każdego z trzech case’ów:

Wrócę do EmDasha, gdy Cloudflare wypuści read replicas dla D1 (latencja −5–10×) i gdy server:defer z batch API stanie się domyślą starter template’a. Wtedy będzie inny artykuł.

Pełna analiza i repozytoria

Pełny artykuł — z surowym results.csv, skryptami bench.sh / analyze.py i komentarzem Jacka po lekturze całości — żyje na shift64.com.

Repozytoria są publiczne:

• Strona EmDash — pełny setup Astro 6 + EmDash + Workers + D1. Branch perf/server-defer-widgets to wersja po optymalizacjach.
• Motyw WordPress (emdash-flavor) — ręczny motyw użyty jako kontrola.

Jeśli umiesz pokazać konfigurację, która sprowadza EmDasha do klasy WordPressa bez ręcznego przepisywania połowy data layera — napisz na X lub LinkedIn. Bardzo chciałbym się mylić.