Ładowanie głównego javascript na każdej stronie? Czy dzielisz go na odpowiednie strony?


13

Mam 700kbzdekompresowany plik JS, który jest ładowany na każdej stronie. Zanim miałem 12pliki javascript na każdej stronie, ale aby zredukować żądania HTTP, skompresowałem je wszystkie 1 file.

Ten plik jest ~130kb gzippedi jest obsługiwany gzip. Jednak na komputerze lokalnym jest nadal rozpakowywany i ładowany na każdej stronie. Czy to problem z wydajnością?

Wyprofilowałem javascript za pomocą firebug profilera, ale nie zauważyłem żadnych problemów. Problem / iluzja, z którą mam do czynienia, polega na tym, że w tym pliku są skompresowane biblioteki jquery, które czasami nie są używane na bieżącej stronie.

Na przykład jquery datatablesjest skompresowany z prędkością 200 KB i jest ładowany tylko na 2 stronach mojej witryny. Inna jest jqploti to jest inna 200kb.

Mam teraz 400kbnadmiar kodu, który nie jest wykonywany na 80%stronach.

Czy powinienem zostawić wszystko w 1 pliku?

Czy powinienem wyjąć biblioteki jquery i załadować tylko odpowiednią JS na bieżącej stronie?


Jeśli masz 700 KB kodu JS, naprawdę powinieneś go ponownie podzielić i uwzględnić tylko te skrypty, których naprawdę potrzebujesz. Ponadto przy użyciu jQuery („… pisz mniej, rób więcej…”) wydaje się, że posiadanie tak dużego pliku JS jest nieco za duże. Co do cholery robisz z taką masą JS?
feeela

@feeela spójrz na jquery-ui, jquery.datatables. Te same mają razem 400 KB. Mam też inne wtyczki, których używam, takie jak jquery.validate, jquery.uniform - te rzeczy się sumują. xD
Kyle

W takim przypadku - jak powiedziano poniżej - naprawdę powinieneś podzielić skrypty i załadować tylko to, co jest potrzebne…
feeela

Odpowiedzi:


6

Za pomocą metody wymaganej można dynamicznie ładować potrzebne biblioteki tylko na tych stronach. Następnie wystarczy załadować wymagane pliki (około 14 KB) na wszystkie strony, oszczędzając około 385 KB.

Integracja jest również bardzo łatwa: wystarczy „owinąć” kod wymaganym kodem:

require(["jquery", "jquery.alpha", "jquery.beta"], function($) {
    //the jquery.alpha.js and jquery.beta.js plugins have been loaded.
    $(function() {
        $('body').alpha().beta();
    });
})

1
Naprawdę podoba mi się ten projekt strony. Nigdy nie słyszałem o wymaganiach. Jak oceniasz to w stosunku do żądań HTTP? Czy to nie stawia więcej żądań HTTP na stronie? (czy to nie takie złe?) Przepraszam za moje głupie pytania.
Kyle

Posiadanie mniejszej liczby wniosków jest oczywiście lepsze, ale oszczędność> 350 tys. Również nie jest taka zła. Tak, Twoja witryna wysyła jeszcze jedno żądanie, jeśli na tej stronie umieścisz inną bibliotekę. Jeśli jest datatablesna jednej stronie, a jqplotna drugiej, nie ma sprawy. Zgadzam się, że załadowanie kolejnych pięciu bibliotek na 50% stron sprawi, że przewaga zniknie. Ale w twoim przypadku uważam to za bardzo dobre rozwiązanie (zakładając, że reszta z was pozostanie jednym plikiem spakowanym gzipem).
Michael

Dzięki Michael. To rozwiązanie jest dość genialne. Zanim zamierzałem podzielić wszystko na jednej stronie, ale to ... To lepsze niż to, co miałem na myśli. Dziękuję za tę sugestię. Skoro znasz Requjs, czy uważasz, że Requjs wystarczyłby? Widzę na niektórych stronach internetowych, których używają Google, aby załadować swój jQuery i innych bibliotek google.load('...').
Kyle

1
Zdecydowanie zalecam ładowanie popularnych bibliotek od Google (lub innych witryn, które je oferują). Ma to dwie zalety: a) plik lib jest buforowany między różnymi stronami. Możliwe, że użytkownik odwiedził wcześniej witrynę, która również korzysta z jquery ładowanej z Google. Ten plik jest następnie ładowany z pamięci podręcznej, a nie z serwera! b) Nawet jeśli to ma być załadowany, to będzie dużo szybciej ładować go z Google CDN, niż z własnego serwera WWW.
Michael

8

Jeśli Twój framework / CMS / cokolwiek posiada odpowiednie funkcje, możesz dołączyć skrypty warunkowo, jak sugeruje @Michael, ale bez dodatkowej biblioteki.

Biorąc na przykład przypadek danych, WordPress może poradzić sobie z sytuacją poprzez:

// For reference; this isn't functional code.
if (is_page('whatever')) {
    <script src="/path/to/datatables.js"><script>
    <script>
        [Your datatables setup here]
    </script>
}

Z RequireJS nie ma nic złego; musisz tylko ocenić, czy dodatkowy poziom złożoności, który dodaje (plus nauka korzystania z niego w pierwszej kolejności) równoważy to, co mogą zrobić dla ciebie bardziej dostępne narzędzia. Jeśli masz tylko dwa przypadki wymienione powyżej, może to być lepsza opcja. Jeśli dzieje się o wiele więcej, RequireJS może być lepszym rozwiązaniem.


Mam niestandardową stronę internetową, którą wykonałem z szablonu HTML, który wcześniej kupiłem. Jedynym problemem jest to, że koleś miał około 6 plików JS rozrzuconych wokół i był brudny. Więc umieściłem je w jednym pliku, który zawiera kilka bibliotek jqplot, datatables, jquery-ui. Wszystkie razem składają się na około 550-600kb. 100 KB to mój JS korzystający z tych bibliotek. Wydaje mi się, że powinienem to naprawić, zamiast ładować tyle niepotrzebnych bibliotek JS na każdej stronie. Dziękuje za twoją sugestię! =)
Kyle

5

700 kB JavaScript to problem z wydajnością, ponieważ musi zostać przeanalizowany po załadowaniu strony. Z tego powodu należy uważać, aby załadować tylko te skrypty, które są potrzebne. Jeden duży JavaScript może być OK na pełnych stronach AJAX, takich jak GMail, gdy nawigacja jest obsługiwana wewnętrznie bez opuszczania pojedynczej strony. Jednak nawet pełne witryny AJAX wykonują dynamiczne ładowanie JS, aby zapobiec ładowaniu niepotrzebnego JS podczas uruchamiania (zarówno problemów z pamięcią, jak i szybkością).

Powiedziałeś, że chcesz zmniejszyć ruch HTTP. Powinieneś grać z buforowaniem HTTP . Problem polega na tym, że zmiany w JS mogą nie być widoczne, dopóki pamięć podręczna nie wygaśnie, jeśli czas wygaśnięcia jest zbyt wysoki.

Istnieje jednak sztuczka, do której się nie odwołujesz myscript.js, ale myscript.js?version={myversion}. Po aktualizacji aplikacji zmieniasz {myversion}i wymuszasz przeładowanie JavaScript.


Tak, przy tej wielkości JS, w połączeniu z faktem, że są to w większości dość powszechne biblioteki, korzystanie z CDN będzie dużą korzyścią.
Zhaph - Ben Duguid

1

~ 700kb JavaScript to problem z wydajnością i jeśli zostanie skompresowany, musimy przestrzegać zasad, których należy przestrzegać podczas optymalizacji kodu:

  1. Minify Javascripts - po prostu kompresujesz i dekompresujesz, co nie zmniejszyło kodu, przede wszystkim skorzystaj z dobrego narzędzia Minify JS i zminimalizuj swój kod. Masz 12 plików, a każdy plik będzie osobno Minify przed klubowaniem, aby uzyskać najlepszą wydajność.

  2. Użyj asynchronicznego ładowania javascript , używając asynchronicznego ładowania powoduje bardzo szybki czas ładowania i renderowania strony. Wpływ użytkownika jest bardzo silny, ponieważ dobre ładowanie asynchroniczne nie blokuje procesu renderowania, a wyczuwalny czas ładowania strony jest znacznie skrócony. Obrazy i inne wyświetlane elementy będą normalnie wyświetlane, gdy javascript nie zostanie załadowany.

  3. Użyj GOOGLE cdn do JQUERY ; Myślę, że używasz JQUERY i ładujesz ją ze swojej strony internetowej, co jest dodatkową zaletą, skorzystaj z GOOGLE CDN ​​(bezpłatnie), aby załadować JQUERY. Ponieważ jest używany przez prawie każdą trzecią stronę internetową, a zatem jest już dostępny na komputerze klienckim w pamięci podręcznej.

  4. Nagłówki niestandardowe długie wygasają : W pewnym sensie, w jaki sposób strona ładuje się z problemem ładowania, musisz podać Długie wygasanie dla plików HTTP JS, aby nie można ich było pobrać za każdym razem, co zmniejszy żądanie po raz drugi. Według moich badań czas ładowania na drugiej stronie ma więcej wyjść w porównaniu do pierwszej wizyty na stronie.

  5. Sprawdź za pomocą szybkości strony : czasami inne zasoby również wpływają na szybkość ładowania strony, a także próbują zoptymalizować inne zasoby. Wykonując trochę kroku na każdym zasobie, poświęć więcej czasu naszemu ładowaniu JS.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.