Najbardziej wydajne wielostronicowe Wymagajjs i Almond setup

Mam wiele stron w witrynie za pomocą RequireJS, a większość stron ma unikalną funkcjonalność. Wszystkie z nich mają wiele wspólnych modułów (jQuery, Backbone i inne); wszystkie mają również własne unikalne moduły. Zastanawiam się, jaki jest najlepszy sposób na optymalizację tego kodu za pomocą r.JS. Widzę wiele alternatyw sugerowanych przez różne części dokumentacji i przykładów RequireJS i Almond - więc wymyśliłem poniższą listę możliwości, które widzę, i pytam który z nich jest najbardziej zalecany (lub jeśli jest inny lepszy sposób):

  1. zoptymalizuj pojedynczy plik JS dla całej witryny , używając Almond, który załaduje się raz, a następnie pozostanie w pamięci podręcznej. Minusem tego najprostszego podejścia jest to, że będę ładowanie na każdym kodzie strony, że użytkownik nie potrzebuje dla tej strony (tj. Moduły specyficzne dla innych stron). Dla każdej strony załadowany JS będzie większy niż musi być.
  2. Optymalizacja pojedynczego pliku JS dla każdej strony , która obejmowałaby zarówno Moduły wspólne, jak i specyficzne dla strony. W ten sposób mogłem dołączyć Almond do pliku każdej strony i załadować tylko jeden plik JS na każdej stronie-który byłby znacznie mniejszy niż pojedynczy plik JS dla całej witryny. Minusem, jaki widzę, jest to, że wspólne Moduły nie byłyby buforowane w przeglądarce, prawda? Dla każdej strony, na którą użytkownik przechodzi, musiałaby ponownie pobrać większość jQuery, szkieletu itp. (wspólne moduły), jak te biblioteki będą stanowiły duże części każdego unikalnego jednostronicowego pliku JS. (Wydaje się, że jest to podejście RequireJS multipage example, z tym wyjątkiem, że przykład nie używa Almond.)
  3. zoptymalizuj jeden plik JS dla wspólnych modułów, a następnie inny dla każdej konkretnej strony . W ten sposób użytkownik buforowałby plik wspólnych modułów i przeglądając między stronami, musiałby załadować tylko mały plik JS specyficzny dla strony. W ramach tej opcji widzę dwa sposoby jej zakończenia, aby Dołącz funkcjonalność RequireJS: a. Załaduj plik wymagaj.js przed wspólnymi modułami na wszystkich stronach, używając składni data-main lub zwykłego znacznika <script> -- w ogóle nie używając Almond. Oznacza to, że każda strona będzie miała trzy pliki JS: require. js, common modules i Page-specific modules. b. wydaje się, że ten gist sugeruje metodę podłączenia Almond do każdego zoptymalizowanego pliku - - - - więc nie musiałbym ładować require.js, ale zamiast tego włączyłby Migdał zarówno w moich wspólnych modułach, jak i w moim Moduły specyficzne dla strony. Naprawdę? Czy jest to bardziej wydajne niż wymaga ładowania.js z góry?

Dzięki za wszelkie porady, które możesz zaoferować, jak najlepiej to zrobić.

Author: davidtheclark, 2013-06-11

5 answers

Myślę, że dość wyraźnie odpowiedziałeś na swoje pytanie.

Do produkcji, robimy - jak również większość firm, z którymi pracowałem Opcja 3 .

Oto zalety rozwiązania 3 i dlaczego uważam, że powinieneś go używać:

  • wykorzystuje większość buforowania , Wszystkie popularne funkcje są ładowane raz . Przy najmniejszym ruchu i generowaniu najszybszych czasów ładowania podczas surfowania po wielu stronach. Czasy ładowania wielu stron są ważne i chociaż ruch po twojej stronie może nie być znaczący w porównaniu do innych zasobów, które ładujesz, klienci naprawdę docenią szybszy czas ładowania.
  • jest to najbardziej logiczne, ponieważ zazwyczaj większość plików w witrynie ma wspólną funkcjonalność.

Oto interesująca zaleta rozwiązania 2:

  • Wysyłasz najmniej danych na każdą stronę. Jeśli wielu odwiedzających jest jednorazowo, na przykład na stronie docelowej - jest to najlepsza opcja. Nie można przecenić czasu ładowania w scenariuszach zorientowanych na konwersję.

  • Czy odwiedzający się powtarzają? niektóre badania sugerują, że 40% odwiedzających ma pusty bufor.

Inne uwagi:

  • Jeśli większość odwiedzających odwiedza jedną stronę-rozważ opcję 2. Opcja 3 jest świetna dla witryn, w których przeciętni użytkownicy odwiedzają wiele stron, ale jeśli użytkownik odwiedza jedną stronę i to wszystko, co widzi - to twoja najlepiej.

  • Jeśli masz dużo JavaScript. Rozważ załadowanie niektórych z nich, aby dać użytkownikowi wizualne wskazanie, a następnie załadowanie reszty w sposób asynchronicznie odroczony (za pomocą script tag injection lub bezpośrednio za pomocą require, jeśli już go używasz). Próg dla osób, które zauważą coś "niezgrabnego" w interfejsie to zwykle około 100ms. przykładem tego jest "ładowanie" Gmaila...' .

  • Biorąc pod uwagę, że połączenia HTTP są Keep-Alive przez domyślnie w HTTP/1.1 lub z dodatkowym nagłówkiem w HTTP / 1.0, wysyłanie wielu plików jest mniejszym problemem niż 5-10 lat temu. Upewnij się, że wysyłasz nagłówek Keep-Alive z serwera dla klientów HTTP / 1.0.

Kilka ogólnych porad i materiałów do czytania:

  • minifikacja JavaScript jest koniecznością, na przykład r.js robi to ładnie i twój proces myślowy w użyciu był poprawny. R. js również łączy JavaScript, który jest krokiem w we właściwym kierunku.
  • Jak zasugerowałem, odroczenie JavaScript jest również bardzo ważne i może drastycznie poprawić czas ładowania. Odroczenie wykonania pomoże Twojemu czasowi ładowania wyglądać szybko, co jest bardzo ważne, o wiele ważniejsze w niektórych scenariuszach niż rzeczywiste szybkie ładowanie.
  • Wszystko, co możesz załadować z CDN, podobnie jak zewnętrzne zasoby, które powinieneś załadować z CDN. Niektóre biblioteki, z których ludzie korzystają dzisiaj jak jQuery, są dość (80kb), pobieranie ich z pamięci podręcznej może naprawdę przynieść ci korzyści. W twoim przykładzie chciałbym Nie załadować szkielet, podkreślenie i jQuery z twojej strony, raczej załadowałbym je z CDN.
 35
Author: Benjamin Gruenbaum,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2013-06-29 23:22:11

Stworzyłem przykładowe repozytorium, aby zademonstrować te 3 rodzaje optymalizacji.

Może pomóc nam lepiej zrozumieć, jak używać r.js.

Https://github.com/cloudchen/requirejs-bundle-examples

 14
Author: cloudchen,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2013-09-09 09:01:30

FYI, wolę użyć opcji 3, podążając za przykładem w https://github.com/requirejs/example-multipage-shim

Nie jestem pewien, czy jest najskuteczniejszy.

Jednak uważam to za wygodne, ponieważ:

  • wystarczy skonfigurować Wymaganie.config (na różnych bibliotekach w jednym miejscu)
  • podczas optymalizacji r. js, następnie zdecyduj, które Moduły grupować jako wspólne
 1
Author: Ian Lim,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2013-06-23 11:57:18

Wolę użyć opcji 3 i z pewnością mogę powiedzieć, dlaczego tak jest.

    To najbardziej logiczne.
  1. wykorzystuje większość buforowania, wszystkie popularne funkcje są ładowane raz. Przy najmniejszym ruchu i generowaniu najszybszych czasów ładowania podczas surfowania po wielu stronach. Czasy ładowania wielu stron są ważne i chociaż ruch po twojej stronie może nie być znaczący w porównaniu do innych zasobów, które ładujesz, klienci naprawdę docenią szybsze ładowanie razy.

Wymieniłem dużo lepsze opcje dla tego samego.

 0
Author: Ramneek Singh,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2014-08-17 10:35:24

Możesz użyć dowolnej sieci dostarczania treści (CDN), takiej jak MaxCDN, aby zapewnić, że Twoje pliki js zostaną udostępnione wszystkim. Również proponuję umieścić swoje pliki js w stopce kodu html. Mam nadzieję, że to pomoże.

 0
Author: Akshay Joshi,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2015-05-10 06:14:04