Dlaczego renderowanie HTML po stronie serwera jest szybsze niż po stronie klienta?

Question

Pracuję nad dużą stroną internetową, a my przenosimy wiele funkcji po stronie klienta (Require.js, stos szkieletu i kierownicy). Istnieją nawet dyskusje na temat przenoszenia całego renderowania po stronie klienta.

Ale czytając niektóre artykuły, szczególnie te dotyczące Twittera odchodzące od renderowania po stronie klienta, które wspominają, że strona serwera jest szybsza/bardziej niezawodna, zaczynam mieć pytania. Nie rozumiem, jak renderowanie dość prostych widżetów HTML w JS z JSON i szablonów jest współczesną przeglądarką na dwurdzeniowym procesorze z 4-8 GB pamięci RAM jest wolniejsze niż tworzenie dziesiątek elementów w aplikacji po stronie serwera. Czy są jakieś rzeczywiste dane porównawcze dotyczące tego?

Wygląda na to, że parsowanie szablonów HTML przez silniki szablonów po stronie serwera nie może być szybsze niż renderowanie tego samego kodu HTML z szablonu Handlebars, szczególnie jeśli jest to funkcja JS wstępnego kompilowania?

Answer 1

Istnieje wiele powodów:

1. JavaScript jest językiem interpretowanym i jest wolniejszy niż po stronie serwera (zwykle odbywa się w skompilowanym języku)
2. manipulacji DOM jest powolny, a jeśli manipulując go w JS it powoduje słabą wydajność. Są sposoby na pokonanie tego, jak przygotowanie tekstu w tekście, a następnie jego ocena, co może w rzeczywistości spowodować, że jesteś tak blisko renderowania po stronie serwera.
3. Niektóre przeglądarki są po prostu zbyt powolne, zwłaszcza stare IE

Answer 2

• Wydajność skompilowany języka kontra interpretowane javascript
• buforowanie, czyli - spełnianie się dokładnie tę samą stronę inny użytkownik już żądany, to usuwa potrzeba dla każdego klienta, aby go renderował. Idealne dla witryn o dużym natężeniu ruchu - np. Witryn z wiadomościami. Micro-caching może nawet zapewnić aktualizacje w czasie zbliżonym do rzeczywistego, ale zapewnia znaczny ruch z pamięci podręcznej. Nie trzeba czekać na klienta renderowania
• Mniejsze uzależnienie od użytkowników ze starych komputerów lub SLOW/kalekie przeglądarek
• tylko trzeba martwić się o świadczenie, mniej polegania na jak różne przeglądarki zarządzać DOM (niezawodność)

Ale w przypadku złożonego interfejsu, renderowanie po stronie klienta interakcji zapewni wygodniejsze wrażenia użytkownika.

To naprawdę zależy od wydajności, którą próbujesz zoptymalizować, oraz od liczby użytkowników.

Answer 3

Aby uruchomić kod po stronie klienta, należy go najpierw załadować. Kod po stronie serwera jest ładowany po uruchomieniu serwera, podczas gdy kod klienta może być ładowany za każdym razem, gdy strona jest. W każdym razie kod musi zostać zinterpretowany podczas ładowania strony, nawet jeśli plik jest już zapisany w pamięci podręcznej. Możliwe, że masz buforowanie plików JS w przeglądarce, ale uważam, że nie są one trwałe, więc nie będą żyły długo.

Oznacza to, że niezależnie od tego, jak szybko JavaScript jest (i jest dość szybki), praca musi zostać wykonana, gdy użytkownik czeka. Wiele badań wykazało, że czas wczytywania strony znacznie wpływa na postrzeganie przez użytkowników jakości i trafności witryn.

Najważniejsze jest to, że masz najwyżej 500ms, aby strona była renderowana z czystego bufora w typowym środowisku programistycznym.Wolniejsze urządzenia i sieci spowodują, że opóźnienia będą ledwo akceptowalne dla większości użytkowników.

Prawdopodobnie masz 50-100ms do robienia rzeczy w JavaScript podczas ładowania strony, wszystko to, suma całkowita, co oznacza, że ​​renderowanie złożonej strony, dobrze, nie jest łatwe.