А аптымізацыі? Гэта агулам нейкае непаханае поле. Гэта ж аптымізаваць SQL запыт, прадставіць індэксы, Java code, працу з масівамі, колькасць перадачы дадзеных, кэшы на ўзроўні сервіса, кэшы на ўзроўні рэгіёна ў AWS, кэшы браўзера, кэшы вэбворкера, кэшы з боку франта на апі запыты, кэшы стану кампанентаў, лэзі лоўдзінг кампанентаў, старонак, прэлоўдзінг стратэгія, js код аптымізацыя, CSS аптымізацыя, Html аптымізацыя, shadow Dom аптымізацыя...
...change detection аптымізацыя, браўзер таск аптымізацыя, rxjs аптымізацыя, аптымізацыя рэндэрынгу спіскаў, візуальная аптымізацыя на старонцы і шмат чаго шчэ, назвы чаго я магу нават не ведаць. І гэта толькі адна тэма ў маім стужку, аптымізацыя, і па факту я амаль нічога не ведаю, як гэта нармальна рабіць (
@hareza_u_kutku звычайна яны распрацаваны так, што асабліва і не трэба нічога рабіць. Налады па змаўчанні павінны працаваць у большасці выпадкаў. часам аптымізацыя без патрэбы робіць код складаным, а рэзультат не вельмі адрозніваецца ад папярэдняга
@xzfantom хв, на вэбе, распрацоўшчыкі заўсёды напішуць праграму, часткі якой будуць лагаць. І тут такі парадокс, ё шмат спосабаў аптымізаваць гэтыя часткі, але адначасова вельмі лёгка і напісаць лагаючы код, бо этапаў выканання праграмы вельмі шмат і суадносна месцаў, дзе можна прафакапіцца з перфомансам дафіга. І гэта часам можна не заўважыць, праз маленькую колькасць сапраўдных даных на дэв асяроддзі, праз дэдлайны, ці праз моцныя камп'ютары, якія ё ў распрацоўшчыкаў, але няма ў карыстальнікаў
@hareza_u_kutku так у тым і сэнс, што трэба аптымізаваць толькі калі ўсе часткі працуюць і іх можна запрафайліць. Няма сэнсу аптымізаваць рэндэрынг, калі адказ з бэкэнду ідзе 5 секунд ці карцінкі якія выкарыстоўваюцца для іконак важаць па 10 мегабайт. Ну і напісаць лагаючы код можна не толькі на вэбе) дарэчы, аптымізацыі сучасных браўзераў гэта проста цуд.