Pracuj\u0105c z r\u00f3\u017cnymi zespo\u0142ami developerskimi, regularnie widz\u0119 jeden problem, kt\u00f3ry przewija si\u0119 przez projekty ma\u0142ych startup\u00f3w i \u015brednich firm \u2013 \u017ale zaprojektowana komunikacja HTTP. To nie jest temat z gatunku \u201ebajery dla architekt\u00f3w\u201d \u2013 to realne pieni\u0105dze i czas, kt\u00f3re wyciekaj\u0105 przez palce.<\/p>\n
Obserwuj\u0119, jak zespo\u0142y marnuj\u0105 godziny na debugowanie op\u00f3\u017anie\u0144, kt\u00f3re wynikaj\u0105 nie z kodu, ale z tego, jak aplikacja rozmawia z API. Zabieram si\u0119 za to nie dlatego, \u017ce lubi\u0119 narzeka\u0107, ale dlatego, \u017ce mam na to proste rozwi\u0105zania.<\/p>\n
Zanim przejdziemy do konkret\u00f3w \u2013 czy wiesz, \u017ce przeci\u0119tna aplikacja webowa wysy\u0142a o 30-50% wi\u0119cej \u017c\u0105da\u0144 HTTP ni\u017c potrzebuje? I \u017ce za ka\u017cdym razem p\u0142acisz za to czasem \u0142adowania, obci\u0105\u017ceniem serwera i frustracj\u0105 u\u017cytkownik\u00f3w?<\/p>\n
Wiele firm wci\u0105\u017c dzia\u0142a na HTTP\/1.1, nawet je\u015bli ich serwer i klient obs\u0142uguj\u0105 nowszy protok\u00f3\u0142. To tak, jakby\u015b mia\u0142 autostrad\u0119, ale jecha\u0142 ni\u0105 rowerem.<\/p>\n
Problem:<\/strong> W HTTP\/1.1 ka\u017cde po\u0142\u0105czenie obs\u0142uguje jedno \u017c\u0105danie na raz. Aby przyspieszy\u0107, deweloperzy cz\u0119sto \u0142\u0105cz\u0105 zasoby (tzw. bundling) \u2013 sklejaj\u0105 CSS, JS, obrazy w jeden plik. To rozwi\u0105zanie z poprzedniej epoki. W HTTP\/2 mo\u017cesz wysy\u0142a\u0107 wiele \u017c\u0105da\u0144 r\u00f3wnolegle na jednym po\u0142\u0105czeniu, a serwer mo\u017ce pushowa\u0107 zasoby, zanim klient ich za\u017c\u0105da.<\/p>\n Przyk\u0142ad:<\/strong> Klient \u2013 startup e-commerce. Mieli problem z szybko\u015bci\u0105 \u0142adowania strony g\u0142\u00f3wnej. Po audycie okaza\u0142o si\u0119, \u017ce u\u017cywaj\u0105 HTTP\/1.1 i \u0142\u0105cz\u0105 wszystkie skrypty w jeden 2MB plik. Przej\u015bcie na HTTP\/2 i podzia\u0142 na mniejsze, r\u00f3wnolegle \u0142adowane modu\u0142y skr\u00f3ci\u0142o czas \u0142adowania o 60%.<\/p>\n Co robi\u0107:<\/strong> W\u0142\u0105cz HTTP\/2 na serwerze. Rozdziel zasoby na mniejsze fragmenty (nie \u0142\u0105cz wszystkiego w jeden plik). Wykorzystaj server push tylko dla krytycznych zasob\u00f3w \u2013 ale ostro\u017cnie, bo nadu\u017cywanie mo\u017ce spowolni\u0107 stron\u0119.<\/p>\n Wi\u0119kszo\u015b\u0107 zespo\u0142\u00f3w wie o Gzip czy Brotli, ale w praktyce cz\u0119sto widz\u0119 serwery, kt\u00f3re nie kompresuj\u0105 odpowiedzi wcale \u2013 albo kompresuj\u0105 tylko HTML, a zapominaj\u0105 o JSON-ie.<\/p>\n Problem:<\/strong> Ka\u017cdy bajt ma znaczenie. Je\u015bli Twoje API zwraca 200KB JSON-a bez kompresji, a z Brotli \u2013 40KB, to r\u00f3\u017cnica w czasie transferu jest kolosalna, zw\u0142aszcza na s\u0142abszych \u0142\u0105czach.<\/p>\n Do tego dochodz\u0105 nag\u0142\u00f3wki. Widz\u0119 odpowiedzi, kt\u00f3re maj\u0105 5-10KB samych nag\u0142\u00f3wk\u00f3w \u2013 g\u0142\u00f3wnie zb\u0119dne ciasteczka, customowe nag\u0142\u00f3wki sesji, kt\u00f3re s\u0105 wysy\u0142ane przy ka\u017cdym \u017c\u0105daniu, nawet gdy niepotrzebne.<\/p>\n Przyk\u0142ad:<\/strong> Platforma SaaS B2B. Ka\u017cda odpowied\u017a API nios\u0142a ze sob\u0105 ca\u0142y obiekt u\u017cytkownika w nag\u0142\u00f3wkach (przez \u017ale skonfigurowany middleware). Po wyczyszczeniu nag\u0142\u00f3wk\u00f3w i w\u0142\u0105czeniu Brotli, wielko\u015b\u0107 odpowiedzi spad\u0142a z 15KB do 2KB. Mno\u017c\u0105c to przez milion \u017c\u0105da\u0144 dziennie \u2013 oszcz\u0119dno\u015b\u0107 transferu i czasu.<\/p>\n Co robi\u0107:<\/strong> W\u0142\u0105cz Brotli (je\u015bli nie, to Gzip). Przejrzyj nag\u0142\u00f3wki \u2013 usu\u0144 te, kt\u00f3re nie s\u0105 niezb\u0119dne. U\u017cywaj nag\u0142\u00f3wka To klasyk. Aplikacja wysy\u0142a to samo \u017c\u0105danie co kilka sekund, mimo \u017ce dane si\u0119 nie zmieni\u0142y. Dotyczy to zar\u00f3wno API, jak i zasob\u00f3w statycznych.<\/p>\n Problem:<\/strong> Ka\u017cde \u017c\u0105danie to koszt \u2013 czasu procesora, przepustowo\u015bci, baterii na urz\u0105dzeniu mobilnym. Nawet je\u015bli odpowied\u017a jest szybka, to narastaj\u0105ca liczba \u017c\u0105da\u0144 przeci\u0105\u017ca serwer i aplikacj\u0119.<\/p>\n Przyk\u0142ad:<\/strong> Klient z bran\u017cy fintech. Ich dashboard od\u015bwie\u017ca\u0142 si\u0119 co 5 sekund, pobieraj\u0105c pe\u0142n\u0105 list\u0119 transakcji (\u015brednio 100KB). Po wdro\u017ceniu cache’owania po stronie klienta (ETag, Last-Modified) i serwera (Redis), liczba rzeczywistych \u017c\u0105da\u0144 spad\u0142a o 70%, a obci\u0105\u017cenie serwera o 50%.<\/p>\n Co robi\u0107:<\/strong> U\u017cywaj nag\u0142\u00f3wk\u00f3w Obrazy to najwi\u0119kszy \u201ezjadacz\u201d transferu. Niestety, wi\u0119kszo\u015b\u0107 firm wrzuca obrazy w pe\u0142nej rozdzielczo\u015bci, bez kompresji, bez format\u00f3w nowej generacji.<\/p>\n Problem:<\/strong> Obraz 2MB z aparatu 12MP na stronie produktowej \u2013 to norma. A wystarczy skompresowa\u0107 do 200KB w WebP, a jako\u015b\u0107 pozostanie akceptowalna. Do tego dochodzi leniwe \u0142adowanie (lazy loading) \u2013 obrazy powinny \u0142adowa\u0107 si\u0119 dopiero, gdy znajd\u0105 si\u0119 w widoku.<\/p>\n Przyk\u0142ad:<\/strong> Sklep odzie\u017cowy. Ka\u017cda strona kategorii mia\u0142a 20 zdj\u0119\u0107 po 1.5MB. Po konwersji na WebP i lazy loading, strona \u0142adowa\u0142a si\u0119 4 razy szybciej, a konwersja wzros\u0142a o 15%.<\/p>\n Co robi\u0107:<\/strong> Kompresuj obrazy (WebP, AVIF). U\u017cywaj srcset dla responsywno\u015bci. Wdr\u00f3\u017c lazy loading. Ponad 50% stron tego nie robi \u2013 to \u0142atwa przewaga.<\/p>\n API, kt\u00f3re zwraca wszystkie rekordy na raz \u2013 to proszenie si\u0119 o k\u0142opoty. Widzia\u0142em endpointy, kt\u00f3re zwraca\u0142y 10 000 rekord\u00f3w, gdy u\u017cytkownik potrzebowa\u0142 tylko 20.<\/p>\n Problem:<\/strong> Du\u017ce odpowiedzi obci\u0105\u017caj\u0105 serwer (wi\u0119cej danych do serializacji), sie\u0107 i klienta (wi\u0119cej danych do parsowania). Do tego klient cz\u0119sto musi przefiltrowa\u0107 dane po stronie przegl\u0105darki, co spowalnia interakcj\u0119.<\/p>\n Przyk\u0142ad:<\/strong> System CRM dla agencji nieruchomo\u015bci. Endpoint Co robi\u0107:<\/strong> Zawsze implementuj paginacj\u0119. U\u017cywaj parametr\u00f3w Optymalizacja komunikacji HTTP to nie fanaberia, a konieczno\u015b\u0107. Ka\u017cda z opisanych zmian to cz\u0119sto kilka godzin pracy, a efekt \u2013 oszcz\u0119dno\u015b\u0107 czasu, pieni\u0119dzy i lepsze do\u015bwiadczenie u\u017cytkownika.<\/p>\n Z w\u0142asnej praktyki widz\u0119, \u017ce firmy, kt\u00f3re ignoruj\u0105 te kwestie, trac\u0105 nie tylko wydajno\u015b\u0107, ale i klient\u00f3w. W dobie Core Web Vitals, szybko\u015b\u0107 strony to czynnik rankingowy i biznesowy.<\/p>\n Zastan\u00f3w si\u0119, ile \u017c\u0105da\u0144 wysy\u0142a Twoja aplikacja. Je\u015bli odpowied\u017a jest d\u0142u\u017csza ni\u017c 5 sekund \u2013 masz problem, kt\u00f3ry warto rozwi\u0105za\u0107.<\/p>\n","protected":false},"excerpt":{"rendered":" Wst\u0119p Pracuj\u0105c z r\u00f3\u017cnymi zespo\u0142ami developerskimi, regularnie widz\u0119 jeden problem, kt\u00f3ry przewija si\u0119 przez projekty ma\u0142ych startup\u00f3w i \u015brednich firm \u2013 \u017ale zaprojektowana komunikacja HTTP. To nie jest temat z gatunku \u201ebajery dla architekt\u00f3w\u201d \u2013 to realne pieni\u0105dze i czas, kt\u00f3re wyciekaj\u0105 przez palce. Obserwuj\u0119, jak zespo\u0142y marnuj\u0105 godziny na debugowanie op\u00f3\u017anie\u0144, kt\u00f3re wynikaj\u0105 nie<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[7],"tags":[422,494,468,431],"class_list":["post-1705","post","type-post","status-publish","format-standard","hentry","category-warto-wiedziec","tag-api-przegladarki","tag-http","tag-optymalizacja-frontendu","tag-optymalizacja-wydajnosci"],"_links":{"self":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/posts\/1705","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/comments?post=1705"}],"version-history":[{"count":0,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/posts\/1705\/revisions"}],"wp:attachment":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/media?parent=1705"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/categories?post=1705"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/tags?post=1705"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}2. Brak kompresji i niew\u0142a\u015bciwe nag\u0142\u00f3wki<\/h2>\n
Cache-Control<\/code>, aby zredukowa\u0107 liczb\u0119 \u017c\u0105da\u0144.<\/p>\n3. Prze\u0142adowanie \u017c\u0105daniami \u2013 brak cache’owania<\/h2>\n
Cache-Control<\/code>, ETag<\/code>, Last-Modified<\/code>. Rozwa\u017c cache warstwy aplikacji (np. Redis, Varnish). Nie pobieraj danych, kt\u00f3re si\u0119 nie zmieni\u0142y \u2013 u\u017cywaj lekkich response’\u00f3w 304 Not Modified.<\/p>\n4. Ignorowanie optymalizacji obraz\u00f3w i zasob\u00f3w<\/h2>\n
5. Zapominanie o paginacji i filtrowaniu<\/h2>\n
\/properties<\/code> zwraca\u0142 wszystkie oferty (5000). Po dodaniu paginacji (limit, offset) i filtr\u00f3w (miasto, cena), odpowied\u017a zmala\u0142a do 20 rekord\u00f3w, a czas odpowiedzi z 2s do 50ms.<\/p>\nlimit<\/code> i offset<\/code> (lub kursora). Zapewnij filtrowanie i sortowanie po stronie serwera. Nie ka\u017c klientowi robi\u0107 tego samemu.<\/p>\nPodsumowanie<\/h2>\n