Defer (Chrom)

Co oznaczają defer i async?

Domyślnie, a <script src=...></script> tag jest zły! przeglądarka musi wstrzymać przetwarzanie HTML do czasu pobrania i wykonania skryptu (ponieważ skrypt może wywołać document.write(...) lub zdefiniować zmienne globalne, od których zależą późniejsze Skrypty). Oznacza to, że obrazy i arkusze stylów znajdujące się po znaczniku script nie rozpoczynają pobierania, dopóki skrypt nie zakończy pobierania i wykonywania. Zewnętrzne Skrypty zazwyczaj powodują, że sieć ładuje się znacznie wolniej, dlatego NoScript stał się tak popularny.

Microsoft wprowadził defer, aby rozwiązać problem. Jeśli używasz <script defer src=...></script>, obiecujesz, że nie zadzwonisz document.write(...). Zewnętrzny skrypt defer rozpocznie pobieranie natychmiast, ale nie zostanie uruchomiony, dopóki strona nie zostanie renderowana. Po wyrenderowaniu strony wszystkie skrypty defer są wykonywane w tej samej kolejności, w jakiej zostały zadeklarowane. Nie wszystkie przeglądarki implementują defer jeszcze.

HTML5 wprowadził atrybut async, który może wykonywać dowolne czas-prawdopodobnie przed zakończeniem parsowania strony lub nawet przed innymi defer/async skrypty, które wciąż się pobierają. Ale trudniej jest używać wielu skryptów async, ponieważ ich kolejność wykonania nie jest gwarantowana. Podobnie jak defer, nie wszystkie przeglądarki implementują async jeszcze.

Po wykonaniu wszystkich skryptów defer i async zdarzenia DOMContentLoaded i load zostaną wywołane.

Krótka historia defer i async

• 1997 IE 4 wprowadza defer.
• 1998 HTML 4 spec Przypisy defer, ale niestety nie mówi dokładnie kiedy defer Skrypty wykonują (wszystko w porządku? Przed onload?). Tak więc, żadne inne przeglądarki nie implementują defer, ponieważ nikt nie chce inżynierii wstecznej zachowań IE lub łamać skryptów, które mogą zależeć od specyfiki IE. (Zobacz na przykład żądanie funkcji Mozilli ).
• 2006 HTML5 draft wreszcie opisuje szczegóły potrzebne do wdrożenia defer: defer Skrypty powinny być wykonywane w kolejności po tym, jak reszta strony jest parsed, a przed onload. Wprowadza również async, aby określić skrypty, które mogą być uruchamiane za każdym razem, gdy są pobierane, bez konieczności czekania na siebie nawzajem. Niestety, HTML5 zaprzecza IE, nie zezwalając na Skrypty inline defer. To łamie niezmienną, że wszystkie skrypty defer są wykonywane w kolejności (jeśli niektóre skrypty defer mają src, a niektóre mają zawartość wbudowaną).
• 2009 Gecko 1.9.1 (Firefox 3.5) obsługuje defer.
• 2010-01 Gecko 1.9.2 (Firefox 3.6) async.
• 2010-09 defer iasync są sprawdzane w Webkit . Powinieneś zobaczyć go w Chrome i Safari już wkrótce (jest już w Chrome Dev channel, ale jest trochę buggy).
• wciąż czekamy na zaimplementowanie przez Operę defer i async oraz na zaimplementowanie przez IE async.

Więc z czego powinien korzystać Web developer?

Nie ma jednej reguły do przestrzegania w tym czasie. Musisz wybrać rozwiązanie, które najlepiej równoważy prostotę, strona opóźnienie renderowania i opóźnienie wykonania skryptu dla zestawu przeglądarek, które uzyskują dostęp do twojej witryny.

• najprostszym sposobem na renderowanie strony przed uruchomieniem skryptów, jak zauważyli inni, jest umieszczenie skryptów na dole strony. Ale jeśli skrypty są niezbędne lub strona internetowa zawiera dużo HTML, powinieneś umieścić swoje skrypty wyżej na stronie.
• jeśli twój skrypt jest samodzielny, a twoi klienci korzystają z IE lub nowych wersji Firefoksa, użyj <script async defer src=...></script>: Pozwala to na kontynuowanie renderowania równolegle do pobierania skryptów dla IE i najnowszych przeglądarek HTML5, ale powoduje blokowanie przeglądarek pre-HTML5 (w tym wszystkich wersji Opery).
• jeśli jeden skrypt zewnętrzny zależy od innego, zaznacz oba defer (ale nie async) i zostaną wykonane w kolejności, w jakiej zostały zadeklarowane (z wyjątkiem IE). Ponownie Pozwala to renderować równolegle do pobierania skryptów w IE i HTML5-aware Gecko / Webkit, ale starsze przeglądarki i Opera będą cierpieć. Dobrym pomysłem jest użycie defer, nawet jeśli skrypty znajdują się na dole strony, tak aby pobierały się równolegle ze sobą.
• nigdy nie używaj defer do skryptów wbudowanych, ponieważ wersja robocza HTML5 odebrała gwarancję zlecenia wykonania.
• jeśli twoja publiczność zawiera wielu użytkowników Opery lub starych Firefoksa / Safari, poniższy fragment wykona skrypt po przetworzeniu dokumentu w większości przeglądarek pre-HTML5 (Tj. Webkit, trzeba przetestować starego Firefoksa), podczas gdy najnowsze przeglądarki obsługujące HTML5 rozpoczynają pobieranie od razu, ale nie blokują wykonania skryptu ze względu na atrybut async. Innymi słowy, większość starszych przeglądarek traktuje go jak skrypt u dołu strony, a najnowsze przeglądarki rozpoznają async. Ale Użytkownicy Opery dostają najgorsze z obu światów, ponieważ Opera natychmiast rozpoczyna wykonywanie i nie rozumie async. Jest to wzór zalecany przez Google Analytics dla urchin na wielu stronach internetowych.

Fragment:

<script>
(function() {
  var script = document.createElement('script');
  script.src = '...';
  script.async = true;
  var s = document.getElementsByTagName('script')[0];
  s.parentNode.insertBefore(script, s);
})();
</script>

• jeśli inny skrypt zależy od pierwszego skryptu do załadowania, wtedy można użyć tego samego wzorca jak powyżej, ale wysłuchać zdarzenia onload pierwszego elementu skryptu przed wykonaniem drugiego skryptu. Zobacz przykład LABjs , aby dowiedzieć się, jak czekać na załadowanie innego skryptu.
• jeśli masz wiele skryptów ze skomplikowanymi zależnościami, użyj LAB.js lub Yui Loader aby je Pobierz równolegle i wykonaj w prawidłowej kolejności.
• jeśli używasz popularnej biblioteki, takiej jak jQuery, rozważ użycie kopii Google zamiast własnej, aby zwiększyć prawdopodobieństwo, że przeglądarka już ją buforowała.

Aktualizacja: jeśli masz Skrypty podzielone na moduły i chcesz poprawić wydajność, polecam rozdział" łączenie skryptów asynchronicznych "jeszcze szybszych stron internetowych autorstwa Steve ' a Soudera. Zawiera porady / triki dla nie tylko kontrolowanie kolejności wykonywania, ale także opóźnianie parsowania skryptów w celu poprawy wydajności.