Co zrobilibyście w celu optymalizacji szybkości działania rozbudowanej aplikacji frontendowej (dowolny framework/biblioteka).Poproszę o kilka propozycji :)
Moze najpierw opisz co juz zrobiliscie zeby wiedziec co brakuje bo tak to troche nie ma sensu wypisywac wszystkiego.
A tak w ogole to optymalizacje po stronie "czego"?
Klienta czyli rendering w przegladarce, jakis lokalny cache, optymalizacje jakiegos fw angular/react/vue
Po stronie serwera? Cdn ?
Jeśli strona nie ma żadnego hasła, ani nie trzeba się logować to wrzuciłbym najpierw na Google pagespeed, a później odpalił devtoolsy + jakieś wtyczki do frameworkow, żeby sprawdzić na czym się ścina. Po zlokalizowaniu przyczyny wystarczy jedynie naprawić.
Ja bym się zastanowil, czy te skomplikowane rozwiązania są konieczne, bo czasem lepiej jest napisać kilka linijek ręcznie, niż wszystko brać z gotowców - patrz syndrom isEven
isOdd
;)
Poza tym sprawdź, co jest wąskim gardłem - serwer się zamula, czy framework do renderowania po stronie frontu zużywa 140% CPU klienta.
Do tego taki standard, czyli lazy loading, może jakieś cachowanie treści (w miarę) statycznych.
- Nie używałabym frejmłorków.
- Zoptymalizowała format/kompresję/wymiary i wagę grafik.
- Zadbała o przesyłanie przez serwer skompresowanych plików.
- Zastanowiła się, czy w danym przypadku renderowanie po stronie klienta faktycznie coś przyspiesza, czy jest używane tylko dlatego, że "wszyscy używają".
Oczywiście wszystko zależy co robisz, dlatego nie ma OGÓLNIE dobrej rady jak optymalizować pod względem szybkości bo nie napisałeś co działa wolno.
Z założenia niemal wszystkie popularne i sensowne narzędzia czy biblioteki działają najszybciej jak to tylko możliwe, a jeżeli coś działa zbyt wolno to błędów należy szukać:
- w projekcie aplikacji,
- pośród błędnie dobranych narzędzi do rozwiązywania danego problemu,
- w algorytmach / logice,
Dzisiaj serwisy internetowe są także aplikacjami, a aplikacje serwisami internetowymi zatem pojęcie "optymalizacji szybkości działania" jest tym bardziej niejasne bowiem:
- czy chodzi o szybkość działania w przeglądarce użytkownika;
- szybkość przygotowania odpowiedzi przez serwer ( to też bezpośrednio przekłada się na szybkość działania u klienta )
- szybkość i minimalizacja czasu pracy serwera by był mniej obciążony wówczas musimy liznąć optymalizacji SEO (jeśli cała aplikacja jest widoczna dla google i robotów ). Źle przygotowany serwis może spowodować, że "roboty" zarżną serwer... a skutek - znów klientowi będzie wolno działać.
Pomińmy nawet kwestie po stronie serwera i załóżmy, że chodzi o sam interfejs... Tutaj dróg też jest wiele.
- możemy przygotowywać odpowiedzi po stronie serwera i przeładowywać i przeładowywać całe podstrony jak to bywało dawniej ale i dziś przy mało złożonych aplikacjach,
- możemy opierać rozwiązanie o jakiś system okienek bazujący na JavaScript - np. ExtJS i całość komunikacji między przeglądarką a serwerem sprowadzić do wymiany małych JSON'ów. W tym przypadku jednak samo ExtJS ma swoje wymagania i przy dużych formularzach lub tabelach z tysiącami wierszy potrafi zamulić.
- możemy napisać samemu prosty lekki front-end w JavaScript i wykorzystać tą samą warstwę komunikacji co w przypadku ExtJS.
Takich pomysłów na sposobów realizacji aplikacji można wymyślać wiele, a każdy będzie miał jakieś "zady i walety" względem innych i tak naprawdę dopóki nie jest sprecyzowane co aplikacja ma robić to niemożliwe jest zaproponowanie optymalnej architektury.
Nawet taka informacja czy ta aplikacja "fron-endowa" działa przez internet czy w ramach sieci lokalnej ma już gigantyczne znaczenie.
Zatem z ogólnych porad można pokusić się jedynie o jakieś banały.
Co do architektury
- jak @cerrato napisał nie używać zbyt wielu zewnętrznych bibliotek do rzeczy wykorzystywanych "sporadycznie" lepiej napisać samemu te kilka linijek kodu.
- nie zaciągać całych zbiorów (assetów) jeśli to nie jest konieczne. Nagminnie otrzymuję projekty, w których z powodu dwóch strzałek do Slidera na stronie doklejają całą bibliotekę font-awesome albo inne fonty google.
- pisać optymalne algorytmy.
- oszczędzać pamięć.
itp...
Co do samego HTML
Faktycznie w dzisiejszych czasach pewnym wyznacznikiem stało się testowanie serwisów różnymi narzędziami zwracającymi bardziej lub mniej sensowne oceny.
Jednym z nich jest wspomniany przez @Xarviel https://developers.google.com/speed/pagespeed/insights/ spośród bardzo wielu dostępnych to dość sensowne narzędzie.
Inne, którymi warto także testować gotowy serwis (jeśli to jest strona internetowa, a nie front-end w JS) to:
- https://validator.w3.org/ ( chyba podstawa i nawet nie trzeba wymieniać )
- https://opengraphcheck.com/result.php?url= ( w czasach "fejsbókuf, tłiteróf i innych nażąduf społecznyh" to też bardzo ważny element )
- https://developers.google.com/search/docs/advanced/structured-data ( narzędzie do testowania danych uporządkowanych )
Jest tylko jedna ogólna porada jak tworzyć aplikacje optymalne i dotyczy wszelkich rodzajów aplikacji...
Trzeba robić to z głową i nie tkwić w schematach.