2013-07-17 6 views
20

Mam pewne zamieszanie wokół nowego atrybutu async do elementu skryptu w HTML5, który mam nadzieję, że ktoś może dać jasną odpowiedź.Czym dokładnie jest korzyść z atrybutu asynchronicznego HTML5 na elementach skryptu?

Przeglądarki obsługują połączenia równoległe, dlatego obrazy będą pobierane równolegle. Jednak zewnętrzny javascript nie jest pobierany równolegle z innymi zewnętrznymi javascriptami i obrazami. Skrypty blokują ładowanie strony, dopóki nie zostaną pobrane i wykonane.

Aby pobrać skrypt bez blokowania reszty ładowania strony, najczęstszym sposobem jest stworzenie elementu skryptu, jak snippet Google Analytics robi:

var ga = document.createElement('script'); 
ga.type = 'text/javascript'; 
ga.src = '...ga.js'; 
ga.async = true; 
var s = document.getElementsByTagName('script')[0]; 
s.parentNode.insertBefore(ga, s); 

nie jestem pewien jak to działa dokładnie - albo

  • przeglądarka analizuje i renderuje stronę, a następnie po jej zakończeniu zauważy DOM uległa zmianie, w wyniku skryptu ga.js pobranie i wykonywane

lub

  • przeglądarka rozpoczyna pobieranie javascript równolegle z innych środków.

Myślę, że to drugie.

Nowy asynchroniczny fragment kodu Google Analytics zawiera atrybut asynchroniczny HTML5 w utworzonym przez niego elemencie skryptu. To nie pomoże w problemie blokowania strony - zostało to już rozwiązane dzięki technice "Script DOM Element". Co więc asynchronicznie dodaje do obrazu? Według w3schools "jeśli async jest obecny, skrypt jest wykonywany asynchronicznie z resztą strony (skrypt zostanie wykonany, gdy strona będzie kontynuowała parsowanie)".

Zgodnie ze słowami Steve'a Soudersa, "główną zaletą tego [asynchronicznego atrybutu] jest informowanie przeglądarki, że kolejne skrypty mogą być natychmiast wykonywane - nie muszą czekać na ga.js".

Więc czy technika asynchronizacji i technika DOM elementu skryptowego rozwiązują ten sam problem?

Dzięki.

Odpowiedz

8

Atrybut asynchroniczny jest bardziej przejrzysty (bez niejasności bardzo prosty) i bardziej przejrzysty (będzie (lub już jest, częścią szanowanej specyfikacji HTML5), aby rozwiązać problem. Jeśli twoja strona obsługuje skrypty z innej domeny (lub CDN), to atrybut asynchroniczny daje ci trochę pewności (pozwól użytkownikowi przynajmniej odczytać zawartość statyczną), że strona nie będzie blokować się, gdy skrypt będzie działał wolno (być może w dół) zdalny host próbuje załadować.

+0

Witam. Dzięki za odpowiedź. Myślę, że zgadzasz się, że nie ma różnicy? Do tego doszedłem, ale zauważyłem, że ten post od szanowanego Steve'a Soudersa sugeruje, że istnieje wyraźna korzyść z używania tagu async ponad techniką elementu DOM skryptu [link] (http: //www.stevesouders .com/blog/2009/12/01/google-analytics-goes-async /). – user265330

+0

@ user265330 - artykuł pochodzi z 2009 roku i nie wspomina o atrybucie ASYNC na znacznikach skryptu. –

+0

Tak, robi. W sekcji "The Async snippet" kod używa zestawu setAttribute do ustawienia asynchronizacji (ok, nie tak, jak w ostatnim fragmencie kodu GA, ale to nie ma znaczenia), a następnie mówi "... atrybut" asynchronizacji "jest ustawiony na "Prawdziwa" Bardzo dobra! Główną zaletą tego jest to, że informuje przeglądarkę, że kolejne skrypty mogą być wykonywane natychmiastowo - nie muszą czekać na ga.js. " – user265330

9

będzie działać:

<script src="//ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js"></script> 
<script>$('body').append('Yey');</script> 

nie będzie działać:

<script async src="//ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js"></script> 
<script>$('body').append('Yey');</script> 
+1

Tak, widzę małych ludzi mówiących o tym ... musisz użyj atrybutu onload = "blah()", aby wykonać twój init po pobraniu skryptu lub w inny sposób po prostu umieść kod init na samym końcu skryptu (nie polegaj na tradycyjnym $ (document) .ready() jednak, bo to już nie zadziała) –

+0

Bardzo dobrze rozwiązany problem! - Chciałbym podkreślić, że podczas gdy druga z pewnością nie będzie działać, pierwsza nie jest pewna. Wystarczy wyrazić zamiar, że to jest to, co jest pożądane ... (w praktyce oczywiście zawijając wszelkie manipulacje domem w imprezie przygotowanej dla DOM ...) –

2

Było świetnie article z Jake Archibald na HTML5Rocks który rozwiązuje ten wątek.

+0

Ale on ma rację, to jest dobry artykuł. +1. – user265330

+0

@millimoose: W artykule przedstawiono różnice i konsekwencje różnych sposobów ładowania skryptu. Więc tak, dostarcza informacji związanych z pytaniem user265330. – cr0

+2

@ cr0 Zazwyczaj zaleca się wykazanie stosowalności tego, co łączysz, poprzez wyciągnięcie z nich najbardziej istotnych części w odpowiedzi. ([Zobacz pytanie w meta.] (Http://meta.stackexchange.com/questions/8231/are-answers-that-just-contain-links-elsewhere-really-good-answers)) Zasadniczo twoja odpowiedź powinna stać własna (której nie ma) i wszystko, co łączysz, powinno dostarczyć dodatkowych informacji. W przeciwnym razie prawdopodobnie zostaniesz upstaged przez kogoś, kto chce włożyć więcej wysiłku. – millimoose

0

Według https://www.html5rocks.com/en/tutorials/speed/script-loading/ jeśli element <script> dodaje dynamicznie to może nie być wykonywane, dopóki DOMContentLoaded jest zwolniony. Oznacza to, że niektóre programy użytkownika (na przykład MSIE 10) będą czekać, aż DOM będzie gotowy przed uruchomieniem dynamicznie dodanych elementów <script>.

Domyślam się, że Google chce, aby ich kod analityki działał szybciej w tych programach użytkownika i jako taki musi dodać flagę async, aby poinformować przeglądarkę (np. MSIE 10), że można rozpocząć wykonywanie skryptu tak szybko, jak to możliwe. Przeglądarki zgodne z HTML5 byłyby wykonywane tak, jakby numer async był prawdziwy, nawet jeśli nie został zdefiniowany, więc async=true został dodany tylko w celu zwiększenia wydajności w przeglądarkach innych niż HTML5.