Jako praktyk od lat zajmuj\u0105cy si\u0119 web developmentem, widz\u0119 pewien schemat: firmy inwestuj\u0105 w pi\u0119kny frontend, dopracowuj\u0105 UX, optymalizuj\u0105 Core Web Vitals, a konwersja i tak nie ro\u015bnie. Zaczynaj\u0105 szuka\u0107 winy w marketingu, cenie czy asortymencie. Tymczasem cz\u0119sto problem le\u017cy g\u0142\u0119biej \u2013 w backendzie, kt\u00f3ry jest niewidoczny dla u\u017cytkownika, ale ma bezpo\u015bredni wp\u0142yw na jego do\u015bwiadczenie.<\/p>\n
W tym artykule poka\u017c\u0119 trzy b\u0142\u0119dy wydajno\u015bciowe backendu, kt\u00f3re obserwuj\u0119 w audytach sklep\u00f3w e-commerce. S\u0105 to problemy realne, kt\u00f3re kosztuj\u0105 sprzeda\u017c, a cz\u0119sto pozostaj\u0105 niezauwa\u017cone przez d\u0142ugi czas.<\/p>\n
Wyobra\u017a sobie sklep, kt\u00f3ry wy\u015bwietla list\u0119 produkt\u00f3w \u2013 ka\u017cdy z nazw\u0105, cen\u0105, zdj\u0119ciem i recenzjami. Frontend wysy\u0142a jedno zapytanie do API, aby pobra\u0107 list\u0119 produkt\u00f3w, a nast\u0119pnie dla ka\u017cdego produktu wysy\u0142a osobne zapytanie o recenzje. To klasyczny problem N+1 queries \u2013 jedno zapytanie g\u0142\u00f3wne i N dodatkowych dla ka\u017cdego elementu.<\/p>\n
W du\u017cym sklepie, gdzie na stronie jest 50 produkt\u00f3w, backend wykonuje 51 zapyta\u0144. Przy 1000 jednoczesnych u\u017cytkownikach robi si\u0119 z tego 51 000 zapyta\u0144 na sekund\u0119. To potrafi zd\u0142awi\u0107 nawet dobrze skonfigurowan\u0105 baz\u0119 danych.<\/p>\n
Przyk\u0142ad z \u017cycia:<\/strong> Co robi\u0107?<\/strong><\/p>\n Cache to jedno z najskuteczniejszych narz\u0119dzi do poprawy wydajno\u015bci backendu, ale tylko je\u015bli jest dobrze skonfigurowany. Wiele firm pope\u0142nia b\u0142\u0105d cache\u2019owania wszystkiego bez zrozumienia, kt\u00f3re dane faktycznie rzadko si\u0119 zmieniaj\u0105.<\/p>\n B\u0142\u0105d 1: Przechowywanie w cache dynamicznych danych.<\/strong> B\u0142\u0105d 2: Brak cache tam, gdzie jest najbardziej potrzebny.<\/strong> Przyk\u0142ad z \u017cycia:<\/strong> Co robi\u0107?<\/strong><\/p>\n W e-commerce wiele operacji nie musi by\u0107 wykonanych natychmiast. Wysy\u0142anie maili potwierdzaj\u0105cych zam\u00f3wienie, generowanie faktur, aktualizacja indeks\u00f3w wyszukiwarki \u2013 to zadania, kt\u00f3re mo\u017cna wykona\u0107 asynchronicznie. Jednak wiele aplikacji wci\u0105\u017c robi to synchronicznie, blokuj\u0105c odpowied\u017a serwera.<\/p>\n Problem:<\/strong> Przyk\u0142ad z \u017cycia:<\/strong> Co robi\u0107?<\/strong><\/p>\n Frontend to wierzcho\u0142ek g\u00f3ry lodowej. Nawet najpi\u0119kniejszy interfejs nie uratuje konwersji, je\u015bli backend nie dzia\u0142a wydajnie. N+1 queries, z\u0142a strategia cache i synchroniczne operacje to trzy b\u0142\u0119dy, kt\u00f3re regularnie spotykam w sklepach e-commerce. Na szcz\u0119\u015bcie ka\u017cdy z nich mo\u017cna wyeliminowa\u0107 stosunkowo prostymi technikami: eager loading, cache warstwowy i asynchroniczne przetwarzanie.<\/p>\n Nast\u0119pnym razem, gdy Twoja strona b\u0119dzie dzia\u0142a\u0107 szybko, ale konwersja b\u0119dzie kule\u0107 \u2013 sp\u00f3jrz na backend. Cz\u0119sto to w\u0142a\u015bnie tam tkwi odpowied\u017a. A je\u015bli potrzebujesz pomocy w audycie wydajno\u015bci, JurskiTech ma w tym do\u015bwiadczenie \u2013 pomagamy firmom znale\u017a\u0107 i wyeliminowa\u0107 te ciche zab\u00f3jc\u00f3w sprzeda\u017cy.<\/p>\n","protected":false},"excerpt":{"rendered":" Dlaczego Tw\u00f3j sklep traci klient\u00f3w mimo idealnego UX? 3 b\u0142\u0119dy wydajno\u015bci backendu Jako praktyk od lat zajmuj\u0105cy si\u0119 web developmentem, widz\u0119 pewien schemat: firmy inwestuj\u0105 w pi\u0119kny frontend, dopracowuj\u0105 UX, optymalizuj\u0105 Core Web Vitals, a konwersja i tak nie ro\u015bnie. Zaczynaj\u0105 szuka\u0107 winy w marketingu, cenie czy asortymencie. Tymczasem cz\u0119sto problem le\u017cy g\u0142\u0119biej \u2013 w<\/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":[776,467,984,24,530],"class_list":["post-2551","post","type-post","status-publish","format-standard","hentry","category-warto-wiedziec","tag-ai-e-commerce","tag-bazy-danych","tag-optymalizacja-api","tag-skalowalnosc","tag-wydajnosc-backendu"],"_links":{"self":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/posts\/2551","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=2551"}],"version-history":[{"count":0,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/posts\/2551\/revisions"}],"wp:attachment":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/media?parent=2551"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/categories?post=2551"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/tags?post=2551"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
\nJeden z klient\u00f3w, sklep z elektronik\u0105, narzeka\u0142 na spadki konwersji w weekendy. Okaza\u0142o si\u0119, \u017ce w szczycie obci\u0105\u017cenia czas odpowiedzi API dla listy produkt\u00f3w wzrasta\u0142 z 200 ms do 3 sekund. Pow\u00f3d? ORM generowa\u0142 N+1 queries dla relacji produkt-kategoria. Wystarczy\u0142o doda\u0107 eager loading (czyli wczytywanie z wyprzedzeniem) i czas spad\u0142 do 250 ms nawet przy du\u017cym ruchu. Konwersja wr\u00f3ci\u0142a do normy.<\/p>\n\n
2. Z\u0142a strategia cache: albo za du\u017co, albo za ma\u0142o<\/h3>\n
\nNiekt\u00f3re sklepy cache\u2019uj\u0105 koszyki zakupowe lub stany magazynowe. To prowadzi do sytuacji, gdzie u\u017cytkownik widzi produkt jako dost\u0119pny, ale po dodaniu do koszyka okazuje si\u0119, \u017ce jest niedost\u0119pny. To prosty spos\u00f3b na utrat\u0119 zaufania.<\/p>\n
\nPrzyk\u0142ad: lista kategorii czy strony produkt\u00f3w mog\u0105 by\u0107 cache\u2019owane przez kilka minut bez ryzyka. Tymczasem wiele sklep\u00f3w generuje je od nowa przy ka\u017cdym od\u015bwie\u017ceniu strony.<\/p>\n
\nSklep odzie\u017cowy mia\u0142 problem z wolnym \u0142adowaniem strony g\u0142\u00f3wnej podczas promocji. Okaza\u0142o si\u0119, \u017ce lista bestseller\u00f3w by\u0142a generowana za ka\u017cdym razem od nowa, cho\u0107 aktualizowa\u0142a si\u0119 raz na godzin\u0119. Wdro\u017cenie Redis cache z TTL 15 minut skr\u00f3ci\u0142o czas generowania strony z 2 sekund do 200 ms.<\/p>\n\n
3. Sync processing tam, gdzie powinno by\u0107 async<\/h3>\n
\nPo z\u0142o\u017ceniu zam\u00f3wienia u\u017cytkownik czeka na potwierdzenie. W mi\u0119dzyczasie backend wysy\u0142a maila, generuje PDF faktury i aktualizuje stan magazynowy. Wszystko synchronicznie. Je\u015bli kt\u00f3ry\u015b z tych krok\u00f3w si\u0119 op\u00f3\u017ani (np. serwer SMTP jest wolny), u\u017cytkownik zobaczy spinner i mo\u017ce pomy\u015ble\u0107, \u017ce zam\u00f3wienie si\u0119 nie z\u0142o\u017cy\u0142o.<\/p>\n
\nPlatforma SaaS oferuj\u0105ca subskrypcje mia\u0142a wysoki wska\u017anik porzuce\u0144 podczas rejestracji. Przyczyn\u0105 by\u0142 synchroniczny proces weryfikacji adresu email, kt\u00f3ry trwa\u0142 nawet 10 sekund. Przeniesienie go do kolejki zada\u0144 (np. RabbitMQ, Sidekiq) skr\u00f3ci\u0142o czas odpowiedzi do 200 ms, a wska\u017anik porzuce\u0144 spad\u0142 o 12%.<\/p>\n\n
Podsumowanie<\/h3>\n