Optymalizacja szybkości frontendu

0

Co zrobilibyście w celu optymalizacji szybkości działania rozbudowanej aplikacji frontendowej (dowolny framework/biblioteka).Poproszę o kilka propozycji :)

1

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 ?

4

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ć.

1

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.

3
  • 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ą".
3

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:

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.

1 użytkowników online, w tym zalogowanych: 0, gości: 1