Dyskretny JavaScript: <script> na górze czy na dole kodu HTML?


90

Niedawno przeczytałem manifest Yahoo Najlepsze praktyki dotyczące przyspieszenia Twojej witryny sieci Web . Zalecają umieszczenie włączenia JavaScript na dole kodu HTML, kiedy tylko jest to możliwe.

Ale gdzie dokładnie i kiedy?

Powinniśmy to umieścić przed zamknięciem </html>czy po? A przede wszystkim, kiedy powinniśmy jeszcze umieścić to w <head>dziale?


Odpowiedzi:


87

Istnieją dwie możliwości tworzenia naprawdę dyskretnych skryptów:

  • w tym zewnętrzny plik skryptu za pośrednictwem tagu script w sekcji head
  • w tym zewnętrzny plik skryptu za pomocą tagu script na dole treści (przed </body></html>)

Drugi może być szybszy, ponieważ oryginalne badanie Yahoo pokazało, że niektóre przeglądarki próbują załadować pliki skryptów po naciśnięciu znacznika skryptu i dlatego nie ładują reszty strony, dopóki nie zakończą. Jednakże, jeśli twój skrypt ma część „gotową”, która musi zostać wykonana, gdy tylko DOM będzie gotowy, być może będziesz musiał mieć to w głowie. Kolejną kwestią jest układ - jeśli skrypt ma zmienić układ strony, to chcesz go załadować tak wcześnie, jak to możliwe, aby strona nie musiała długo rysować się przed użytkownikami.

Jeśli zewnętrzna witryna skryptowa znajduje się w innej domenie (np. Zewnętrzne widżety), warto umieścić ją na dole, aby nie opóźniała ładowania strony.

W przypadku jakichkolwiek problemów z wydajnością przeprowadź własne testy porównawcze - to, co może być prawdą w pewnym momencie, gdy badanie jest wykonywane, może się zmienić wraz z lokalną konfiguracją lub zmianami w przeglądarkach.


13
Odnośnie skryptu mającego „gotową” część. Umieszczenie tego skryptu na dole ciała gwarantuje, że DOM jest gotowy do manipulacji, jeśli umieścisz go w głowie, musisz go owinąć, aby czekał na zdarzenie DOMReady (lub podobne)
Juan Mendes

4
@Juan Tak, ale umieszczając skrypt na dole, opóźniasz zdarzenie DOMReady o czas potrzebny przeglądarce na przeanalizowanie dokumentu i przetworzenie elementów head (200-500 ms), zanim zażąda tego skryptu . Głównie podczas ładowania pierwszej strony (zakładając, że można ją stamtąd buforować). Natomiast jeśli umieścisz go w głowie. Prawdopodobnie będzie gotowy znacznie szybciej. Więc mając na uwadze HTML5, jeśli skrypt musi zmodyfikować układ, gdy DOM jest gotowy, teraz lepiej będzie mieć w głowie skrypt „async” lub „defer”.
hexalys

31

Nigdy nie jest tak wycięty i suchy - Yahoo zaleca umieszczanie skryptów tuż przed </body>tagiem zamykającym , co stworzy iluzję, że strona ładuje się szybciej na pustej pamięci podręcznej (ponieważ skrypty nie blokują pobierania reszty dokumentu). Jeśli jednak masz kod, który chcesz uruchomić podczas ładowania strony, rozpocznie się on dopiero po załadowaniu całej strony. Jeśli umieścisz skrypty w <head>tagu, zaczną się one uruchamiać wcześniej - więc w przygotowanej pamięci podręcznej strona będzie się ładować szybciej.

Ponadto przywilej umieszczania skryptów na dole strony nie zawsze jest dostępny. Jeśli chcesz uwzględnić w swoich widokach wbudowane skrypty, które zależą od biblioteki lub innego kodu JavaScript, który został wcześniej załadowany, musisz załadować te zależności w <head>tagu.

Podsumowując, zalecenia Yahoo są interesujące, ale nie zawsze mają zastosowanie i powinny być rozpatrywane indywidualnie dla każdego przypadku.


1
Jeśli masz dyskretny skrypt javscript, nie będziesz mieć wbudowanych fragmentów kodu, a pytanie wyraźnie wspomniało, że jest dyskretne.
Juan Mendes

1
<script>tagi wbudowane nie oznaczają natrętnego kodu JavaScript.
Eran Galperin

@Eric Galperin: Jakie jest dobre zastosowanie wbudowanych tagów skryptów, które nie są natrętne?
Juan Mendes

4
@Juan natrętny Javascript oznacza, że ​​interfejs użytkownika jest uszkodzony bez niego lub jest osadzony w znacznikach. <script>Tagi są niezależne od znaczników i mogą być używane z kodem, który ulepsza interfejs, ale nie jest wymagany. Dlatego <script>tagi wbudowane nie są z natury irytujące .
Eran Galperin

4
1. Nazywam się Eran, a nie Eric, 2. Gdy chcesz przekazać dane do JavaScript z języka po stronie serwera, na przykład w pętli elementów, możesz użyć <script>tagów do zakodowania tych wartości w zmiennych javascript, do użytku np. edycja bezpośrednia lub inne podobne zachowanie.
Eran Galperin

22

Jak powiedzieli inni, umieść go przed zamykającymi tagami HTML body .

Niedawno otrzymaliśmy wiele telefonów od klientów, którzy skarżyli się, że ich witryny działają bardzo wolno. Odwiedziliśmy ich lokalnie i stwierdziliśmy, że załadowanie jednej strony zajęło im 20-30 sekund. Myśląc, że serwery działają źle, zalogowaliśmy się - ale zarówno serwery WWW, jak i sql były ~ 0% aktywności.

Po kilku minutach zdaliśmy sobie sprawę, że zewnętrzna witryna nie działa, do której łączyliśmy się z tagami śledzenia JavaScript. Oznaczało to, że przeglądarki naciskały na tag skryptu w sekcji głównej witryny i czekały na pobranie pliku skryptu.

Tak więc, przynajmniej w przypadku skryptów innych firm / zewnętrznych, zalecałbym umieszczenie ich na ostatniej stronie. Gdyby były niedostępne, przeglądarka przynajmniej do tego momentu załadowałaby stronę - a użytkownik byłby tego nieświadomy.


10
Fajna historia bracie :) Ale poważnie, to jest najbardziej przekonujący argument, jaki widziałem, dotyczący umieszczania tagów skryptów na dole strony.
user271608

16

Podsumowując, w oparciu o powyższe sugestie:

  1. W przypadku skryptów zewnętrznych (Google Analytics, narzędzia do śledzenia marketingu firm zewnętrznych itp.) Umieść je przed </body>tagiem.
  2. W przypadku skryptów wpływających na układ strony umieść w nagłówku.
  3. W przypadku skryptów, które opierają się na „dom ready” (np. Jquery), rozważ umieszczenie go przed, </body>chyba że masz ważny powód, aby umieścić skrypty w głowie.
  4. Jeśli istnieją wbudowane skrypty z zależnościami, umieść wymagane skrypty w nagłówku.

6

Jeśli chcesz majstrować przy pozycji swoich skryptów, YSlow jest świetnym narzędziem do nadawania smaku, jeśli ma to poprawić lub zaszkodzić wydajności. Umieszczenie javascript w niektórych pozycjach dokumentu może naprawdę skrócić czas ładowania strony.

http://developer.yahoo.com/yslow/


5

Nie, nie powinno być po, </html>ponieważ byłoby to nieważne. Najlepszym miejscem do umieszczania skryptów jest tuż przed rozszerzeniem</body>

Dzieje się tak po prostu dlatego, że większość przeglądarek przestaje renderować stronę podczas oceny dostarczonego przez Ciebie skryptu. Tak więc w porządku jest umieszczanie kodu nieblokującego w dowolnym miejscu na stronie (myślę głównie o rzeczach, które dołączają funkcje do onLoadzdarzenia, ponieważ wiązanie zdarzeń jest tak szybkie, że jest efektywnie wolne). Wielki zabójca znajduje się na początku strony, umieszczając skrypt serwera reklam, który może zapobiec wczytywaniu strony przed całkowitym pobraniem reklam, sprawiając, że czas ładowania strony się wydłuża


Wiesz, jeśli naprawdę zależy ci na szybkości, nie będzie żadnych </body> ani </html> - znaczniki zamykające dla tych typów elementów są opcjonalne. Umieść <script> na samym końcu i całkowicie zapomnij o używaniu </body> i </html>.
Jim

9
Miejmy nadzieję, że Jim jest sarkastyczny - w każdym razie nie słuchaj jego rady. Dobrze sformułowany XHTML wymaga zamykania tagów dla każdego elementu, w tym tagów body i html. Jeśli twój kod nie jest prawidłowym XML, robisz to źle.
Matt Lohkamp

6
Nie, nie jestem sarkastyczny. Spójrz na pytanie. Określa HTML, a nie XHTML. Prawdą jest, że poprawny XHTML wymaga tych rzeczy, ale poprawny HTML tego nie wymaga. Nie ma absolutnie nic złego w wyborze HTML i pomijaniu zamykających tagów dla tych typów elementów.
Jim

2

Jeśli umieścisz go na dole, ładuje się jako ostatni, co przyspiesza prędkość, z jaką użytkownik może zobaczyć stronę. Musi być przed finałem, </html>ale w przeciwnym razie nie będzie częścią DOM.

Jeśli jednak kod jest potrzebny natychmiast, umieść go w głowie.

Najlepiej umieścić elementy takie jak widżety bloga na dole, aby jeśli się nie ładowały, nie wpłynęło to na użyteczność strony.

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.