Audyt wydajności

Audyt ma dwa poziomy. Pierwszy to audyt wejściowy: niewielka stała cena, a od Ciebie potrzebujemy tylko adresu sklepu.

Audyt wejściowy

Wyślij nam adres swojego sklepu. Zmierzymy go od zewnątrz: Lighthouse, Core Web Vitals z danych realnych użytkowników tam, gdzie są dostępne, do tego pisemna lista trzech poprawek, od których sami byśmy zaczęli. Wyniki omawiamy na rozmowie 30–60 minut. Jeśli wyniki są prawidłowe, napiszemy to wprost.

Głęboka analiza

Tygodniowe zlecenie o ustalonym zakresie. Kończy się pisemnym raportem i konkretnym planem napraw.

• Real-user metrics. Core Web Vitals z ruchu produkcyjnego, pobrane z Cloudflare Web Analytics, Vercel Speed Insights albo jednorazowym zapytaniem do CrUX, a nie z syntetycznego testu w pojedynczej instancji Chrome.
• Trace po stronie serwera: rozbicie TTFB per route, czasy zapytań do bazy, profil wywołań third-party, cache hit rate.
• Audyt bundli i assetów: co wysyłasz do przeglądarki, co blokuje render, a co powinno być ładowane lazy, preloadowane albo usunięte. Obrazy, fonty, JS, CSS, cały transfer.
• Priorytetyzowany plan napraw. Każdy problem dostaje oszacowanie pracy, spodziewany efekt (w milisekundach, a w konwersji tam, gdzie dane pozwalają na szacunek) oraz ryzyko, a całość jest posortowana według ROI. Jeśli budżetu starcza tylko do piątego wiersza, możesz na nim poprzestać.

Pobierz przykładowy raport (PDF). Klient w nim jest fikcyjny; struktura, poziom szczegółu i bezpośredniość ocen odpowiadają dokładnie temu, co otrzymasz.

Co taki audyt znajduje

Prawdziwe znaleziska ze sklepów, przy których pracowaliśmy przez lata, bez nazw:

• Każda karta produktu spędzała ~300 ms, a czasem całe sekundy, w synchronicznym serwerowym wywołaniu API marketingowego, przy każdym pojedynczym wyświetleniu. Znalazł to trace transakcji; przeniesienie wywołania do kolejki usunęło problem, z liczbami przed i po na dowód.
• Cache hit rate stał w miejscu na 20–30%, bo rozszerzenie od statusów magazynowych czyściło cały cache Varnisha po każdym zamówieniu. Dostawca zaprzeczał, więc sprawę rozstrzygnęła reprodukcja na czystej instalacji z zapisami z varnishlog.
• Checkout przestał działać w całym sklepie przy zamówieniu #65 536: tabela jednego z dostawców miała klucz główny typu SMALLINT, którego zakres się wyczerpał.
• Zapytanie katalogowe 110 razy wolniejsze, niż powinno, z trzema nałożonymi na siebie przyczynami: platforma z założenia prosiła silnik wyszukiwania o 10 000 identyfikatorów, regresja w wersji bazy danych to wzmacniała, a na wierzchu moduł zewnętrznego dostawcy psuł schemat API.
• Nocny import, którego czas urósł z 6 do 48 minut. Przyczyną był cron czyszczący, który przestał działać bez zgłoszenia błędu i zostawił tabelę staging o rozmiarze 8 GB w bazie mającej łącznie 13 GB.
• Lista zamówień klienta przyspieszyła z 3,5 s do 800 ms, gdy zapytanie przestało pobierać pełne szczegóły zamówienia dla każdego wiersza na liście.

Wolne sklepy rzadko są wolne z powodu, który wszyscy podejrzewają. Właśnie dlatego zaczynamy od pomiarów.

Kiedy to ma sens

• TTI powyżej 2,5 s, a konwersja odbiega od oczekiwań
• Rozważasz replatforming i chcesz najpierw wiedzieć, czy problemem faktycznie jest wydajność
• Nowa funkcja pogorszyła wyniki i nikt nie wie, która
• Potrzebujesz drugiej opinii technicznej przed podpisaniem większej umowy

Cena

Audyt wejściowy ma niewielką stałą cenę, ustaloną z góry. Głęboka analiza również ma stałą cenę, zależną od rozmiaru stacku. Większość zleceń trwa 5–10 dni roboczych i kończy się planem napraw, który możesz zrealizować z dowolnym zespołem, także własnym.