Wstęp
W ostatnich latach obserwuję ciekawy trend. Firmy prześcigają się w implementacji nowoczesnych frameworków frontendowych. React, Next.js, Vue – każdy chce mieć szybki, interaktywny interfejs. Tymczasem największym wąskim gardłem wydajności nie jest frontend, tylko backend. Możesz mieć najlżejszy interfejs świata, ale jeśli API odpowiada w 3 sekundy, użytkownik i tak poczuje frustrację.
W tym artykule pokażę trzy realne scenariusze, w których słaby backend niszczy wysiłki frontendowców. Są to sytuacje z życia wzięte – widziałem je u klientów, którzy przyszli z problemem „strona jest wolna”, a po audycie okazywało się, że to nie wina kodu po stronie klienta.
1. N+1 zapytań – cichy zabójca wydajności
Zaczniemy od klasyka. Wyobraź sobie sklep e-commerce, który wyświetla listę produktów. Na froncie pobierasz listę 20 produktów, a następnie dla każdego z nich wykonujesz osobne zapytanie o cenę, stan magazynowy, opinie i zdjęcia. Efekt? 1 + 4*20 = 81 zapytań do bazy danych dla jednego widoku. Przy 1000 odwiedzających dziennie to 81 000 zapytań – potężne obciążenie.
Najgorsze jest to, że programiści frontendowi często nie widzą tego problemu. Narzędzia deweloperskie w przeglądarkach pokazują tylko czas odpowiedzi API, a nie to, ile zapytań generuje backend. Dlatego klient mówi: „frontend działa wolno”, podczas gdy w rzeczywistości to backend robi za dużo pracy.
Przykład z życia: Klient prowadzący sklep z odzieżą. Strona główna ładowała się 8 sekund. Okazało się, że backend dla każdego produktu pobierał osobno dane z trzech tabel. Po dodaniu eager loadingu (czyli pobraniu wszystkich danych w jednym zapytaniu) czas spadł do 1,2 sekundy. Zero zmian w frontendzie.
Co zrobić? Audytuj zapytania do bazy. Narzędzia jak Django Debug Toolbar czy Rails Panel pokazują liczbę zapytań na stronę. Cel to poniżej 10 zapytań dla typowego widoku. Używaj mechanizmów N+1 detector w ORM-ach.
2. Brak cache’owania API – płacisz każdym requestem
Drugi częsty grzech to brak cache’owania odpowiedzi API. Nawet jeśli backend jest szybki, to generowanie tej samej odpowiedzi dla każdego użytkownika jest marnotrawstwem. Lista produktów, kategorie, stopka – to dane, które zmieniają się rzadko. A tymczasem wielu programistów generuje je na nowo przy każdym żądaniu.
Problem polega na tym, że frontendowcy często projektują interfejs tak, by pobierać dane w czasie rzeczywistym. To świetne dla komponentów dynamicznych, ale oznacza, że backend musi obsłużyć setki zapytań na sekundę dla tych samych danych.
Scenariusz: Strona bloga z najnowszymi wpisami. Każdy odwiedzający pobiera listę artykułów. Jeśli nie ma cache’a, serwer przy 1000 użytkownikach generuje 1000 zapytań do bazy. Z cache’em Redis lub Varnish – tylko pierwsze zapytanie idzie do bazy, reszta z pamięci podręcznej. Różnica w czasie odpowiedzi: 300 ms vs 5 ms.
Realny przypadek: Firma z branży turystycznej. Ich backend generował listę wycieczek na podstawie skomplikowanych kalkulacji. Czas odpowiedzi API wynosił średnio 1,2 sekundy. Po wprowadzeniu cache’a z okresem ważności 5 minut – spadł do 15 ms. Wzrost konwersji o 12% tylko dlatego, że lista wycieczek ładowała się błyskawicznie.
Wskazówka: Zidentyfikuj endpointy, które zwracają dane rzadko zmieniające się. Dodaj cache na poziomie aplikacji (Redis, Memcached) lub użyj CDN z cache’owaniem API. Ustaw odpowiednie nagłówki Cache-Control.
3. Zbyt ciężkie odpowiedzi API – frontend nie ma szans
Trzeci problem to przesyłanie zbyt dużych ilości danych. Frontend często potrzebuje tylko kilku pól z modelu, a backend wysyła cały obiekt wraz z relacjami, historią zmian i metadanymi. Im większa odpowiedź, tym dłuższy czas transferu, a na słabszych łączach – większe ryzyko błędu.
Przykład: Aplikacja do zarządzania projektami. Endpoint GET /tasks zwraca dla każdego zadania: ID, tytuł, opis, osobę przypisaną, historię zmian, komentarze, załączniki. W odpowiedzi jest 15 KB na zadanie. Przy 100 zadaniach to 1,5 MB. Dla użytkownika na LTE to może być 2-3 sekundy samego transferu.
Tymczasem frontend potrzebuje tylko ID, tytułu i osoby przypisanej do wyświetlenia listy. Reszta danych jest niepotrzebna i obciąża zarówno backend, jak i frontend.
Rozwiązanie: Stosuj GraphQL lub przynajmniej dedykowane endpointy z możliwością wyboru pól (sparse fieldsets w REST). Dzięki temu frontend decyduje, co pobierać. Można też dodać paginację i filtrowanie po stronie backendu – nie pobieraj wszystkich rekordów, jeśli użytkownik ogląda tylko pierwsze 10.
Przypadek z życia: Startup SaaS oferujący dashboard. Ich główny widok łączył dane z 6 różnych endpointów, każdy zwracał pełne obiekty. Po wprowadzeniu dedykowanego endpointu zwracającego tylko potrzebne pola (i złączonego w jedno zapytanie), czas ładowania strony spadł z 5,2 sekundy do 0,8 sekundy. Wzrost retencji użytkowników o 15%.
Podsumowanie
Słaby backend to najszybszy sposób, aby zniszczyć wrażenia użytkownika, nawet jeśli masz najlepszy frontend na świecie. Zanim zaczniesz optymalizować kod po stronie klienta, sprawdź fundamenty:
- Czy API odpowiada szybko?
- Czy używa cache?
- Czy zwraca tylko potrzebne dane?
Bo jeśli backend jest wąskim gardłem, żaden frontend tego nie ukryje.
