Historycznie problem szybkości ładowania rozważano wyłącznie jako metrykę inżynieryjną, ale z wdrożeniem Core Web Vitals do algorytmów wyszukiwania i wzrostem ruchu mobilnego stało się oczywiste, że wydajność to cecha produktowa. Klasyczne podejścia do oceny wpływu szybkości napotykają na fundamentalną endogeniczność: użytkownicy z szybkim sprzętem i stabilnym internetem konwertują lepiej niezależnie od optymalizacji strony, co tworzy spurioliczną korelację.
Problem ten pogłębia się w przypadku użycia Edge Computing i nowoczesnych architektur CDN, gdzie nie można zapewnić spójnego podziału ruchu na grupy z powodu agresywnego buforowania na serwerach brzegowych. Ponadto występuje efekt samo-selekcji: użytkownicy z wolnym połączeniem częściej opuszczają stronę przed załadowaniem, co zniekształca rozkład w próbie i uniemożliwia czyste porównanie A/B.
Optymalne rozwiązanie łączy Regression Discontinuity Design (RDD) na granicy progu „dobrej” wydajności (np. LCP = 2,5 sekundy) z instrumental variables (IV) jako narzędziem. Jako zmienną instrumentalną wykorzystuje się geograficzną bliskość użytkownika do najbliższego edge-serwera lub typ połączenia (3G vs 4G), co przypadkowo wpływa na szybkość, ale nie koreluje bezpośrednio z intencją dokonania zakupu. Do analizy kohortowej stosuje się synthetic control method, gdzie grupa kontrolna jest konstruowana z historycznych danych użytkowników o podobnej strukturze urządzeń i geolokalizacjach, co umożliwia odizolowanie czystego efektu optymalizacji od sezonowości i makro-trendów.
W dużym projekcie e-commerce zespół front-endowy przeprowadził rewolucję: przekształcił obrazy na nowoczesne formaty (WebP, AVIF) z lazy-loadingiem i zoptymalizował krytyczną ścieżkę renderowania, zmniejszając LCP z 4,2 sekundy do 1,8 sekundy wśród użytkowników z dobrym połączeniem. Zespół produktowy odnotował wzrost konwersji o 12% w segmencie „po wydaniu”, ale pojawiły się wątpliwości co do przyczynowo-skutkowej zależności, ponieważ równolegle uruchomiono sezonową kampanię reklamową i zaktualizowano katalog produktów.
Opcja 1: Naiwne porównanie kohort przed i po
Analitycy zaproponowali porównanie konwersji użytkowników przez tydzień przed optymalizacją i tydzień po, stratyfikując według regionów. Zalety: prostota wdrożenia i brak potrzeby w skomplikowanej infrastrukturze. Wady: całkowite zignorowanie sezonowości (tydzień przedświąteczny), różnic w składzie audiencji (nowi użytkownicy przybyli z reklamy z innym zamiarem) i przeżywalności (survivorship bias) — wolni użytkownicy „zniknęli” z po-wyboru, tworząc iluzję wzrostu.
Opcja 2: Analiza korelacyjna prędkości vs konwersji
Drugie podejście zakładało zbudowanie regresji, gdzie zmienną niezależną był faktyczny LCP użytkownika, a zmienną zależną — fakt konwersji. Zalety: wykorzystanie wszystkich dostępnych danych i granularity do sesji. Wady: fatalna endogeniczność: użytkownicy z drogimi flagowymi urządzeniami i szybkim internetem od początku są bogatsi i bardziej zmotywowani do zakupu, a użytkownicy z tanimi urządzeniami na 3G mają niski intent-to-buy niezależnie od szybkości strony, co daje współczynnik przesunięcia w górę na 40-60%.
Opcja 3: Regression Discontinuity Design z geograficznym narzędziem
Zespół wybrał hybrydową metodę: wykorzystał odległość do najbliższego edge-serwera jako zmienną instrumentalną, korelującą ze szybkością, ale nie z zachowaniem zakupowym. Użytkownicy na granicy zasięgu (gdzie sygnał „łamie się” i szybkość nagle spada do 2,6-2,8 sekundy LCP) stworzyli lokalnie losową próbkę wokół progu 2,5 sekundy. Stosując Local Average Treatment Effect (LATE) w oknie ±0,3 sekundy od progu, zmierzyli czysty efekt poprawy szybkości dla compilers (użytkowników, których szybkość zmieniła się wyłącznie z powodu infrastruktury, a nie urządzenia).
Wybrane rozwiązanie i wynik
Zrealizowano podejście RDD+IV z dodatkowym filtrowaniem użytkowników powracających przez analizę localStorage pod kątem buforowanych zasobów. Ostateczna ocena pokazała, że prawdziwy inkrementalny efekt optymalizacji wyniósł +8,5% do konwersji dla nowych użytkowników i +3,2% dla powracających (gdzie efekt nowości jest mniejszy), co pozwoliło uzasadnić inwestycje w infrastrukturę Edge Computing z ROI 340% w roku.
Dlaczego standardowa regresja OLS wydajności vs konwersji daje zniekształcone oceny, i jaki mechanizm endogeniczności tutaj dominuje?
Odpowiedź leży w podwójnej samo-selekcji (double selection bias): po pierwsze, użytkownicy z wolnymi urządzeniami systematycznie rzadziej trafiają do próby „udanych sesji” (znikają przed załadowaniem), tworząc truncation bias; po drugie, szybkość internetu koreluje z status statusu społeczno-ekonomicznego i geografi, które bezpośrednio wpływają na zdolność płatniczą. Bez zmiennych instrumentalnych lub RDD regresja myli efekt „szybkiego internetu jako wskaźnika bogactwa” z efektem „szybkiej strony jako wyzwalacza konwersji”, przeszacowując prawdziwy efekt przyczynowy 1,5-2 razy.
Jak buforowanie po stronie klienta (client-side caching) i powracające wizyty zniekształcają ocenę efektu optymalizacji w analizie longitudinalnej, i jaka metoda pozwala odfiltrować „zanieczyszczenie leczenia”?
Użytkownicy powracający, którzy odwiedzili stronę przed optymalizacją, mają w HTTP-cache lub Service Worker stare, ciężkie zasoby, więc dla nich „leczenie” (nowa szybka wersja) częściowo lub całkowicie nie ma zastosowania, tworząc contamination between treatment and control. Kandydaci często zapominają sprawdzić nagłówki If-None-Match lub analizować first-party cookie z timestamp pierwszej wizyty. Poprawne podejście — analiza intent-to-treat (ITT) z podziałem na „czyste nowe sesje” (nowi użytkownicy + czyszczony cache) vs „zanieczyszczone powracające”, lub wykorzystanie difference-in-differences (DiD) z efektami stałymi użytkownika, co izoluje zmiany wewnątrz użytkownika od selekcji między użytkownikami.
Jaka jest różnica między analizą ITT (Intent-to-Treat) a analizą TOT (Treatment-on-the-Treated) przy ocenie efektu Core Web Vitals, i dlaczego dla metryk produktowych krytycznie jest raportować dokładnie ITT przy planowaniu skalowania?
ITT mierzy efekt dla całej populacji, w tym tych, którzy nie otrzymali poprawy szybkości (np. użytkownicy na 2G lub z wyłączonym JavaScript), podczas gdy TOT (lub LATE w kontekście IV) mierzy efekt tylko dla „compilers” — tych, którzy rzeczywiście otrzymali korzyść z optymalizacji. Kandydaci często błędnie informują biznes o ocenie TOT (+15% konwersji dla tych, którzy otrzymaliby szybkie ładowanie), ale przy skalowaniu optymalizacji na 100% ruchu rzeczywisty efekt będzie bliżej ITT (+6-8%), ponieważ część audytorium technicznie nie będzie mogła otrzymać poprawy (stare urządzenia, wolne sieci). Dla planowania biznesowego i prognozowania przychodów kluczowe jest wykorzystanie konserwatywnej oceny ITT, aby uniknąć błędu overcommitment.