Znasz to uczucie, gdy aplikacja webowa dzia\u0142a p\u0142ynnie na Twoim laptopie, ale na starszym telefonie klienta klatkuje, a interfejs laguje? Wi\u0119kszo\u015b\u0107 problem\u00f3w z wydajno\u015bci\u0105 rozwi\u0105zuje si\u0119 optymalizacj\u0105 kodu JavaScript, ale s\u0105 przypadki, gdzie JS po prostu nie wystarczy. I tu wkracza WebAssembly \u2013 technologia, kt\u00f3ra obiecuje wydajno\u015b\u0107 zbli\u017con\u0105 do natywnej. Pytanie tylko: czy ma\u0142a firma potrzebuje takiego rozwi\u0105zania?<\/p>\n
W ostatnich latach WASM przesta\u0142o by\u0107 nisz\u0105. Wykorzystuj\u0105 je Adobe (Photoshop w przegl\u0105darce), Figma (edytor graficzny) czy Google Earth. Ale czy Tw\u00f3j sklep e-commerce lub SaaS obs\u0142uguj\u0105cy kilkaset u\u017cytkownik\u00f3w dziennie co\u015b na tym zyska? O tym w\u0142a\u015bnie jest ten artyku\u0142.<\/p>\n
Pierwsza rzecz, kt\u00f3r\u0105 trzeba zrozumie\u0107: WebAssembly nie przyspieszy Twojej strony g\u0142\u00f3wnej. Nie sprawi, \u017ce obrazki za\u0142aduj\u0105 si\u0119 szybciej. Nie skr\u00f3ci czasu odpowiedzi API. WASM to technologia przeznaczona do zada\u0144 obliczeniowych \u2013 takich, kt\u00f3re w JavaScript s\u0105 w\u0105skim gard\u0142em.<\/p>\n
Pracowa\u0142em niedawno z klientem \u2013 sklep z meblami na zam\u00f3wienie. Mieli w panelu klienta modu\u0142 konfiguratora 3D, kt\u00f3ry pozwala\u0142 wybra\u0107 kolor, materia\u0142 i wymiary. Pocz\u0105tkowo napisany w Three.js (JavaScript) dzia\u0142a\u0142 przyzwoicie na desktopach, ale na tabletach i telefonach zwalnia\u0142 do 10 klatek na sekund\u0119. Po przepisaniu logiki renderowania do WebAssembly (w praktyce C++ skompilowanego do WASM) uda\u0142o si\u0119 uzyska\u0107 30 klatek r\u00f3wnie\u017c na s\u0142abszych urz\u0105dzeniach. R\u00f3\u017cnica by\u0142a odczuwalna \u2013 u\u017cytkownicy przestali pomija\u0107 konfigurator.<\/p>\n
Wniosek:<\/strong> WASM ma sens, gdy masz zadanie obliczeniowe (obr\u00f3bka wideo, symulacje, renderowanie 3D, skomplikowane algorytmy kryptograficzne), kt\u00f3re w JS dzia\u0142a oci\u0119\u017cale.<\/p>\n Nie ma sensu u\u017cywa\u0107 WASM do wy\u015bwietlenia listy produkt\u00f3w czy walidacji formularza. Po co wi\u0119c rozwa\u017ca\u0107 t\u0119 technologi\u0119? Oto konkretne przypadki:<\/p>\n Je\u015bli Twoja aplikacja g\u0142\u00f3wnie wysy\u0142a zapytania do API i wy\u015bwietla wyniki, WASM nie da Ci korzy\u015bci. Nawet je\u015bli dzisiaj masz spory ruch, skalowanie backendu b\u0119dzie bardziej op\u0142acalne ni\u017c wprowadzanie nowej warstwy technologicznej.<\/p>\n WebAssembly nie jest darmowe. Opr\u00f3cz oczywistych zalet, niosie ze sob\u0105 wyzwania:<\/p>\n Wi\u0119kszo\u015b\u0107 j\u0119zyk\u00f3w kompilowanych do WASM to C++, Rust lub Go. Je\u015bli Tw\u00f3j zesp\u00f3\u0142 zna tylko JavaScript, b\u0119dziesz musia\u0142 zatrudni\u0107 kogo\u015b nowego lub przeszkoli\u0107 obecny personel. To koszt czasu i pieni\u0119dzy.<\/p>\n Narz\u0119dzia deweloperskie dla WASM nie s\u0105 jeszcze tak dojrza\u0142e jak dla JS. Debugowanie b\u0142\u0119d\u00f3w w Rustcie uruchomionym w przegl\u0105darce potrafi by\u0107 uci\u0105\u017cliwe. Stack trace s\u0105 cz\u0119sto mniej czytelne, a profiler mniej szczeg\u00f3\u0142owy.<\/p>\n WASM mo\u017ce generowa\u0107 wi\u0119ksze pliki ni\u017c por\u00f3wnywalny kod JS \u2013 szczeg\u00f3lnie je\u015bli u\u017cywasz ca\u0142ego \u015brodowiska uruchomieniowego. Powoduje to d\u0142u\u017cszy czas pierwszego \u0142adowania. W jednym z projekt\u00f3w, gdzie zastosowali\u015bmy WASM do biblioteki kryptograficznej, plik wa\u017cy\u0142 1.5 MB, co w przypadku u\u017cytkownik\u00f3w z wolnym internetem (np. w Polsce na LTE na wsi) wyd\u0142u\u017cy\u0142o czas \u0142adowania nawet o 2 sekundy.<\/p>\n Je\u015bli widzisz potencja\u0142 w WASM, nie musisz od razu przepisywa\u0107 ca\u0142ej aplikacji. Oto plan dzia\u0142ania:<\/p>\n Znajomy startup \u2013 aplikacja webowa do podpisywania dokument\u00f3w. U\u017cytkownik przesy\u0142a PDF, a aplikacja dodaje pole podpisu i wysy\u0142a do podpisania. Pocz\u0105tkowo przetwarzanie PDF odbywa\u0142o si\u0119 po stronie backendu (w Pythonie). Ka\u017cdy plik przechodzi\u0142 przez serwer, co przy wzro\u015bcie ruchu zacz\u0119\u0142o generowa\u0107 op\u00f3\u017anienia i koszty utrzymania serwer\u00f3w.<\/p>\n Przepisano logik\u0119 parsowania i renderowania PDF do WebAssembly (w \u015brodowisku asm.js\/emscripten). Teraz przetwarzanie odbywa si\u0119 w przegl\u0105darce u\u017cytkownika. Backend odczu\u0142 mniejsze obci\u0105\u017cenie, a u\u017cytkownicy szybciej widz\u0105 efekt. Koszt implementacji: oko\u0142o 2 tygodnie pracy developera znaj\u0105cego C++, ale zwr\u00f3ci\u0142o si\u0119 ju\u017c po 3 miesi\u0105cach dzi\u0119ki obni\u017ceniu rachunk\u00f3w za serwery.<\/p>\n WebAssembly nie jest srebrn\u0105 kul\u0105. Dla wielu ma\u0142ych firm to nadal egzotyka, kt\u00f3ra nie przynosi wymiernych korzy\u015bci. Ale je\u015bli Twoja aplikacja ma cho\u0107 jeden obszar, w kt\u00f3rym JS zwalnia, a szybko\u015b\u0107 ma wp\u0142yw na konwersj\u0119 \u2013 warto rozwa\u017cy\u0107. Zaczynaj od ma\u0142ego, mierz efekty, a dopiero potem skaluj.<\/p>\n W JurskiTech.pl sami wdra\u017camy WASM tam, gdzie ma to sens \u2013 nie dla mody, tylko dla realnej poprawy wydajno\u015bci. Je\u015bli zastanawiasz si\u0119, czy Twoja aplikacja mog\u0142aby zyska\u0107 na tej technologii \u2013 rzu\u0107 okiem na swoje logi wydajno\u015bci. A je\u015bli potrzebujesz wsparcia w analizie \u2013 daj zna\u0107.<\/p>\n","protected":false},"excerpt":{"rendered":" Wprowadzenie Znasz to uczucie, gdy aplikacja webowa dzia\u0142a p\u0142ynnie na Twoim laptopie, ale na starszym telefonie klienta klatkuje, a interfejs laguje? Wi\u0119kszo\u015b\u0107 problem\u00f3w z wydajno\u015bci\u0105 rozwi\u0105zuje si\u0119 optymalizacj\u0105 kodu JavaScript, ale s\u0105 przypadki, gdzie JS po prostu nie wystarczy. I tu wkracza WebAssembly \u2013 technologia, kt\u00f3ra obiecuje wydajno\u015b\u0107 zbli\u017con\u0105 do natywnej. Pytanie tylko: czy ma\u0142a<\/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":[265,570,431,79],"class_list":["post-2016","post","type-post","status-publish","format-standard","hentry","category-warto-wiedziec","tag-architektura-frontendu","tag-mala-firma","tag-optymalizacja-wydajnosci","tag-webassembly"],"_links":{"self":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/posts\/2016","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=2016"}],"version-history":[{"count":0,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/posts\/2016\/revisions"}],"wp:attachment":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/media?parent=2016"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/categories?post=2016"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/tags?post=2016"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}2. Kiedy ma\u0142a firma realnie zyska na WASM?<\/h3>\n
\n
Kiedy poczeka\u0107?<\/h4>\n
3. 3 ukryte koszty wdro\u017cenia WASM<\/h3>\n
a) Kompetencje zespo\u0142u<\/h4>\n
b) Debugowanie i narz\u0119dzia<\/h4>\n
c) Rozmiar plik\u00f3w<\/h4>\n
4. Jak zacz\u0105\u0107 ma\u0142ym kosztem?<\/h3>\n
\n
5. Przyk\u0142ad z rynku: Jak ma\u0142a aplikacja do edycji PDF skorzysta\u0142a na WASM?<\/h3>\n
Podsumowanie<\/h3>\n