Wstęp
Pracując z różnymi zespołami developerskimi, regularnie widzę jeden problem, który przewija się przez projekty małych startupów i średnich firm – źle zaprojektowana komunikacja HTTP. To nie jest temat z gatunku „bajery dla architektów” – to realne pieniądze i czas, które wyciekają przez palce.
Obserwuję, jak zespoły marnują godziny na debugowanie opóźnień, które wynikają nie z kodu, ale z tego, jak aplikacja rozmawia z API. Zabieram się za to nie dlatego, że lubię narzekać, ale dlatego, że mam na to proste rozwiązania.
Zanim przejdziemy do konkretów – czy wiesz, że przeciętna aplikacja webowa wysyła o 30-50% więcej żądań HTTP niż potrzebuje? I że za każdym razem płacisz za to czasem ładowania, obciążeniem serwera i frustracją użytkowników?
1. Niewykorzystane możliwości HTTP/2
Wiele firm wciąż działa na HTTP/1.1, nawet jeśli ich serwer i klient obsługują nowszy protokół. To tak, jakbyś miał autostradę, ale jechał nią rowerem.
Problem: W HTTP/1.1 każde połączenie obsługuje jedno żądanie na raz. Aby przyspieszyć, deweloperzy często łączą zasoby (tzw. bundling) – sklejają CSS, JS, obrazy w jeden plik. To rozwiązanie z poprzedniej epoki. W HTTP/2 możesz wysyłać wiele żądań równolegle na jednym połączeniu, a serwer może pushować zasoby, zanim klient ich zażąda.
Przykład: Klient – startup e-commerce. Mieli problem z szybkością ładowania strony głównej. Po audycie okazało się, że używają HTTP/1.1 i łączą wszystkie skrypty w jeden 2MB plik. Przejście na HTTP/2 i podział na mniejsze, równolegle ładowane moduły skróciło czas ładowania o 60%.
Co robić: Włącz HTTP/2 na serwerze. Rozdziel zasoby na mniejsze fragmenty (nie łącz wszystkiego w jeden plik). Wykorzystaj server push tylko dla krytycznych zasobów – ale ostrożnie, bo nadużywanie może spowolnić stronę.
2. Brak kompresji i niewłaściwe nagłówki
Większość zespołów wie o Gzip czy Brotli, ale w praktyce często widzę serwery, które nie kompresują odpowiedzi wcale – albo kompresują tylko HTML, a zapominają o JSON-ie.
Problem: Każdy bajt ma znaczenie. Jeśli Twoje API zwraca 200KB JSON-a bez kompresji, a z Brotli – 40KB, to różnica w czasie transferu jest kolosalna, zwłaszcza na słabszych łączach.
Do tego dochodzą nagłówki. Widzę odpowiedzi, które mają 5-10KB samych nagłówków – głównie zbędne ciasteczka, customowe nagłówki sesji, które są wysyłane przy każdym żądaniu, nawet gdy niepotrzebne.
Przykład: Platforma SaaS B2B. Każda odpowiedź API niosła ze sobą cały obiekt użytkownika w nagłówkach (przez źle skonfigurowany middleware). Po wyczyszczeniu nagłówków i włączeniu Brotli, wielkość odpowiedzi spadła z 15KB do 2KB. Mnożąc to przez milion żądań dziennie – oszczędność transferu i czasu.
Co robić: Włącz Brotli (jeśli nie, to Gzip). Przejrzyj nagłówki – usuń te, które nie są niezbędne. Używaj nagłówka Cache-Control, aby zredukować liczbę żądań.
3. Przeładowanie żądaniami – brak cache’owania
To klasyk. Aplikacja wysyła to samo żądanie co kilka sekund, mimo że dane się nie zmieniły. Dotyczy to zarówno API, jak i zasobów statycznych.
Problem: Każde żądanie to koszt – czasu procesora, przepustowości, baterii na urządzeniu mobilnym. Nawet jeśli odpowiedź jest szybka, to narastająca liczba żądań przeciąża serwer i aplikację.
Przykład: Klient z branży fintech. Ich dashboard odświeżał się co 5 sekund, pobierając pełną listę transakcji (średnio 100KB). Po wdrożeniu cache’owania po stronie klienta (ETag, Last-Modified) i serwera (Redis), liczba rzeczywistych żądań spadła o 70%, a obciążenie serwera o 50%.
Co robić: Używaj nagłówków Cache-Control, ETag, Last-Modified. Rozważ cache warstwy aplikacji (np. Redis, Varnish). Nie pobieraj danych, które się nie zmieniły – używaj lekkich response’ów 304 Not Modified.
4. Ignorowanie optymalizacji obrazów i zasobów
Obrazy to największy „zjadacz” transferu. Niestety, większość firm wrzuca obrazy w pełnej rozdzielczości, bez kompresji, bez formatów nowej generacji.
Problem: Obraz 2MB z aparatu 12MP na stronie produktowej – to norma. A wystarczy skompresować do 200KB w WebP, a jakość pozostanie akceptowalna. Do tego dochodzi leniwe ładowanie (lazy loading) – obrazy powinny ładować się dopiero, gdy znajdą się w widoku.
Przykład: Sklep odzieżowy. Każda strona kategorii miała 20 zdjęć po 1.5MB. Po konwersji na WebP i lazy loading, strona ładowała się 4 razy szybciej, a konwersja wzrosła o 15%.
Co robić: Kompresuj obrazy (WebP, AVIF). Używaj srcset dla responsywności. Wdróż lazy loading. Ponad 50% stron tego nie robi – to łatwa przewaga.
5. Zapominanie o paginacji i filtrowaniu
API, które zwraca wszystkie rekordy na raz – to proszenie się o kłopoty. Widziałem endpointy, które zwracały 10 000 rekordów, gdy użytkownik potrzebował tylko 20.
Problem: Duże odpowiedzi obciążają serwer (więcej danych do serializacji), sieć i klienta (więcej danych do parsowania). Do tego klient często musi przefiltrować dane po stronie przeglądarki, co spowalnia interakcję.
Przykład: System CRM dla agencji nieruchomości. Endpoint /properties zwracał wszystkie oferty (5000). Po dodaniu paginacji (limit, offset) i filtrów (miasto, cena), odpowiedź zmalała do 20 rekordów, a czas odpowiedzi z 2s do 50ms.
Co robić: Zawsze implementuj paginację. Używaj parametrów limit i offset (lub kursora). Zapewnij filtrowanie i sortowanie po stronie serwera. Nie każ klientowi robić tego samemu.
Podsumowanie
Optymalizacja komunikacji HTTP to nie fanaberia, a konieczność. Każda z opisanych zmian to często kilka godzin pracy, a efekt – oszczędność czasu, pieniędzy i lepsze doświadczenie użytkownika.
Z własnej praktyki widzę, że firmy, które ignorują te kwestie, tracą nie tylko wydajność, ale i klientów. W dobie Core Web Vitals, szybkość strony to czynnik rankingowy i biznesowy.
Zastanów się, ile żądań wysyła Twoja aplikacja. Jeśli odpowiedź jest dłuższa niż 5 sekund – masz problem, który warto rozwiązać.
