Powolne API: dlaczego tracisz klientów nawet nie wiedząc o tym
Znasz to uczucie? Strona działa błyskawicznie, ale użytkownicy i tak odchodzą. Dzwonisz do programistów, a oni mówią: „frontend jest szybki, backend też”. Tylko że klienci mówią co innego. Często problem leży nie w szybkości renderowania, ale w opóźnieniach na poziomie API. Dziś pokażę Ci, jak ciche spowolnienia backendu niszczą konwersję i co z tym zrobić.
1. Sekwencyjne zapytania tam, gdzie powinny być równoległe
Zdarzyło mi się audytować aplikację e-commerce, która ładowała stronę produktu w 3 sekundy. Frontend był skompilowany, obrazy skompresowane, ale coś nie grało. Okazało się, że backend wysyłał zapytania do API po kolei: najpierw o produkt, potem o cenę, potem o stan magazynowy – każde czekało na poprzednie. Zmiana na zapytania równoległe skróciła czas ładowania do 1,2 sekundy. Konwersja wzrosła o 18%.
Jak to naprawić?
- Na froncie używaj
Promise.alllub podobnych mechanizmów do niezależnych wywołań. - Po stronie backendu rozważ agregujące endpointy (GraphQL lub dedykowane endpointy kompozytowe).
- Mierz czasy każdego wywołania osobno – często jedno wolne zapytanie blokuje resztę.
2. Zbyt duże payloady – wysyłasz całą bazę zamiast tego, co potrzebne
Klient z branży SaaS narzekał na długie ładowanie listy zamówień. W odpowiedzi z API leciało 50 pól na zamówienie, podczas gdy interfejs potrzebował tylko 5. Payload ważył 2 MB – dla 100 zamówień na stronie to 200 MB transferu. Po optymalizacji do 10 pól, czas odpowiedzi spadł z 1,5 s do 200 ms.
Jak to naprawić?
- Wprowadź paginację z limitem pól (np.
fields=id,nazwa,data). - Używaj GraphQL lub dedykowanych endpointów do konkretnych widoków.
- Kompresuj odpowiedzi (gzip, brotli).
- Streamuj duże zbiory danych zamiast wysyłać je w jednym kawałku.
3. Brak cache’owania – każde żądanie generuje nowe zapytanie do bazy
Widziałem sklep, gdzie API za każdym razem liczyło dostępność produktu z bazy danych. Przy 10 000 odwiedzin dziennie to 10 000 zapytań SQL, z których 90% zwracało ten sam wynik. Wdrożenie cache Redis na poziomie API skróciło średni czas odpowiedzi z 800 ms do 50 ms.
Jak to naprawić?
- Cache’uj odpowiedzi na poziomie CDN i serwera.
- Ustaw odpowiednie nagłówki
Cache-ControliETag. - Dla danych dynamicznych używaj inwalidacji cache przy zmianach.
- W przypadku skomplikowanych obliczeń rozważ wstępne generowanie wyników.
Podsumowanie
Powolne API to zabójca konwersji, ale często pozostaje niezauważone, bo skupiamy się na szybkości frontendu. Warto regularnie mierzyć czasy odpowiedzi API, audytować payloady i wdrażać cache. Pamiętaj: każda milisekunda ma znaczenie dla Twojego biznesu.
