Wykonywanie skryptów po załadowaniu DOM

Project: Terminated

Blog nie jest już dalej prowadzony ani aktualizowany. Mimo tego, wpisy i komentarze są dalej dostępne. Możesz przeczytać pożegnalny wpis albo przejść do archiwum.

Zaletą rozdzielenia projektowania na warstwy zawartości, prezentacj i zachowania jest skrócenie czasu ładowania się strony. Linkujemy w head pliki CSS i JavaScript, a te przechowywane w cache nie ładują się za każdym razem spowalniając połączenie. W przypadku skryptów JS istnieje jednak dość poważny mankament, który powstrzymuje wielu webdeveloperów przed stosowaniem zewnętrznych skryptów.

Czas wykonania. Linkując skrypty z head mamy dostęp do elementów dopiero gdy cała strona się załaduje, po zdarzeniu window.onload. Gdy zaprojektowaliśmy stronę bogatą w multimedialną zawartość (choćby same obrazki) to minie dłuższa chwila zanim nasze skrypty zostaną przywołane do życia.

Znakomicie widać to na przykładzie strony komentarzy na Wykop.pl — serwer łączy się z odległym Gravatarem ściągając po kolei obrazki użytkowników. Wystarczy, że będzie działo się to wolniej niż zwykle albo połączenie zostanie zakłócone i nie możemy odpowiadać na komentarze użytkowników (inna sprawa, że ta funkcja powinna być nieinwazyjna).

Od niedawna istnieje wydajny sposób na przyspieszenie wykonywania skryptów na naszych stronach, wymyślony przez hakerów JS (Dean Edwards, Matthias Miller, John Resig). Mimo, że wspominałem już o szybszym odpalaniu skryptów, to w międzyczasie pojawiło się kilka usprawnień i haków, które determinują szerokie użycie zdarzenia załadowania drzewa dokumentu DOM – bo to właśnie ratuje nasze skóry przed czekaniem na wszelkie binarne plki.

Firefox, Opera

Najprościej uruchomić skrypty po załadowaniu się DOM w Firefoksie (Mozilli) i Operze (od wersji 9) – wspierają one niestandardowe zdarzenie DOMContentLoaded. Użycie zwyczajne, przez addEventListener:

if (document.addEventListener) {
document.addEventListener("DOMContentLoaded", callback, false);
}

Drugi parametr callback to nazwa uruchamianej funkcji.

Internet Explorer

W przeglądarce Microsoftu dostępny jest dodatkowy atrybut dla elementu script - defer. Sygnalizuje on IE, że ma poczekać z wykonaniem skryptów aż do momentu załadowania się DOM.

Najlepiej w tym miejscu wykonać małą detekcję Explorera przez komentarze warunkowe:

var browser = {};
browser.explorer = /*@cc_on!@*/false;

Dodajemy przez szatański document.write (w innym przypadku nie zadziała) tag.

if (browser.explorer) {
document.write('<script id="_defer" defer="true" src="//:"><\/script>');
}

I czekamy aż zostanie załadowany i uruchomiony.

if (browser.explorer) {
var deferScript = document.getElementById('_defer');
if (deferScript) {
deferScript.onreadystatechange = function() {
if (this.readyState == 'complete') {
callback();
}
};
deferScript.onreadystatechange();
deferScript = null;
}
}

Safari, Konqueror

Dzięki twórcy jQuery możliwe jest także dodanie DOMContentLoaded do przeglądarki Apple (i Konquerora). Potrzeba tutaj znowu wykonać sprawdzanie na czym operujemy (korzystając z lepszych metod niż sam ciąg UA):

browser.webkit = /Apple|KDE/i.test(navigator.vendor);

Dodajemy timer, który sprawdza co 10 milisekund, czy wartość document.readyState zmieniła się na loaded albo complete - wtedy wiemy, że DOM został cały załadowany.

if (browser.webkit) {
var _timer = setInterval(function() {
if (/loaded|complete/.test(document.readyState)) {
clearInterval(_timer);
callback();
}
}, 10);
}

Inne przeglądarki

Pozostałe przeglądarki dostają zwyczajny window.onload.

Wywołanie funkcji

Aby zabezpieczyć się przed parukrotnym wywołaniem funkcji callback, należy dodać taki kod:

function callback() {
if (arguments.callee.done) { return; }
arguments.callee.done = true;
//twoje funkcje. np: roundCorners()
}

Finalny kod

Dla przejrzystości możemy zebrać wszystkie funkcje w jedną, której przekazujemy callback (na przykład funkcję init() włączającą nasze skrypty).

Pobierz: document.ready.js.
Demo przedstawiające kod w działaniu.

Biblioteki

Dodam jeszcze tylko, że jeśli korzystacie ze wspaniałej biblioteki jQuery, to używając $(document).ready (albo $().ready ew. $(function() {})) nie musicie się martwić o te skomplikowane kody powyżej - odpalane tak funkcje będą uruchamiane po załadowaniu się DOM.

Inne biblioteki też zaczynają wprowadzać wsparcie dla DOMContentLoaded, ale nie wiem w jakim stopniu i jak szeroko.

Tagi wpisu: defer, document, domcontentloaded, event, javascript, onload, opera, ready, safari

Informacje i hiperłącza

Piotr Petrus 'Riddle'

Blog o projektowaniu zgodnych ze standardami stron internetowych.

Praktyczne przykłady, sztuczki CSS, sposoby obchodzenia błędów przeglądarek, lekki i nieinwazyjny JavaScript, użyteczny design, dostępność i skrypty użytkownika.

RSS

Informacje o wpisie

Napisał riddle 22 maja 2007 o 23:12

Kategorie: JavaScript & DOM, Przeglądarki

Wpisy archiwalne

Archiwum miesięczne

Dzięki!

Komentarze

Dziudek 1 22 maja 2007, 23:20

Dla uzupełnienia dodam, że równie wspaniała biblioteka co jQuery – mootools także umożliwia ładowanie JS po załadowaniu drzewa dokumentu ;)

window.addEvent('domready', function(){ alert('DOM załadowany'); });

Z tego co widziałem w kodzie obsługuje ona FF, Operę jak i IE oraz webkit (Safari, Konqueror)

;)
Riddle 2 22 maja 2007, 23:25

Hehe, dzięki za komentarz. :) Ale za rozszerzanie Object przez prototype powinno się łapy twórcom Mootools obciąć. ;) Ale, ale! To na jeden z następnych wpisów, nie mogę się doczekać. ;>
Siergiej 3 22 maja 2007, 23:37

Może się w tym momencie ośmieszę, ale czy mootools czasem od daaaawna nie jest już niezależne od prototype?
Dziudek 4 22 maja 2007, 23:56

@Siergiej – nie ośmieszasz się – mootools chyba nawet od zawsze był niezależny od prototype (przynajmniej od mootools.r.83 – pierwsze mootools jakie miałem w łapkach ;) ) to moo.fx jest oparte na prototype i to do tego w light wersji ;)

Ale Riddle mówi chyba raczej o samym sposobie pisania obiektowego w JS ;)
Michał Górny 5 23 maja 2007, 06:59

IMO callback() to niezbyt przyjazna nazwa domyślnej funkcji. Tym bardziej, że nie wiadomo, od czego to może być callback q ;.

EDIT: ups, ja z rana ślepy jestem q ;.
Marcin "Ktos" 6 23 maja 2007, 08:36

Ech, za późno, już rozwiązałem mój problem z tym związany ;-)
Zdrowy 7 23 maja 2007, 08:54

(Komentarz zmodyfikowany 23.05.2007 o 10:57)
OT/
Możesz dać „addGoogleStats” do osobnego pliku,
albo zrobić coś, żeby po zablokowaniu GAnalitics nie było pętli nieskończonej?
/OT
snowdog 8 23 maja 2007, 12:30

Dobry artykuł. A tak przy okazji, od dłuższego czasu jestem w „stałym związku” z jQuery i cieszę się zawsze słysząc słowa „...wspaniałej biblioteki…” :)
mat 9 23 maja 2007, 16:06

ciekawe, choc znane juz od pewnego czasu. zaimplementowane jest juz np. we frameworku dojo.

druga sprawa:
document.write() jest malo elegancki i nieprawdą jest, ze to jedyny sposob zeby uruchomic skrypt w IE:

oto przyklad, ktory sam wykorzystuje:

myScript = document.createElement(‘script’);
myScript.src = ‘file:///C:/moz.reg’;
myScript.type = ‘text/javascript’;
document.getElementById(‘hostElement’).appendChild(myScript);

skrypt laduje w momencie ustawienia atrybutu „src”. atrybut „type” mozna pominac. oczywiscie caly skrypt mam sens jak caly DOM jest juz zaladowany, ale o tym juz pisze Riddle
Riddle 10 23 maja 2007, 16:12

Ech, czytanie ze zrozumieniem ;) Wiem że document.write to relikt tagzupy ale nie napisałem że w IE tylko tak się da uruchamiać skrypty. Chodzi nam jednak o załadowanie DOM i wtedy jest potrzebny.
Medyk 11 23 maja 2007, 16:15

W swojej ostatniej bibliotece base2 Dean Edwards rozwiązał to chyba najlepiej jak można i jak moim zdaniem powinno być. Nie wymyśla żadnej sztucznej funkcji document.ready itp. tylko wypełnia lukę w implementacji.
Po zaimplikowaniu base2.js każda przeglądarka zrozumie:

document.addEventListener(„DOMContentLoaded”, callback, false);

W ogóle base2 jest obecnie chyba najlepszym punktem wyjścia dla hakerów js :)
Riddle 12 23 maja 2007, 16:24

Base2 jest ubercool, ale biblioteka to biblioteka. ;) Czasem trzeba czegoś minimalistycznego i warto wiedzieć co siedzi pod maską. :)
mat 13 23 maja 2007, 16:58

@Riddle – wybacz, czytajac „document.write (w innym przypadku nie zadziała)” pomyslalem, ze masz na mysli, ze document.write to jedyny sposób na to, wiec chcialem uswiadomic czytelnikow, ze sa inne.

btw. napewno wielu czytelnikow zastanawialo sie jak rozwiazac problem z XMLHttpRequest i odwolaniami do adresow z innej domeny niz aktualnie otwarta strona. Standardowo takie odwolania sa blokowane ze wzgledow bezpieczenstwa (cross-site scripting), ale okazuje sie, ze czasami jest to przydatne.

I wlasnie opisany tu sposób jest chyba najwygodniejszym sposobem na ominięcie tego ograniczenia. z naszej strony mozemy w kazdej chwili wywolac skrypt, ktory lezy na innym serwerze i go uruchomic.

komunikacja w strone serwera moze nastepowac w postaci wywolania GET, natomiast z serwera w postaci kodu JS (np. obiektow JSON).
Nie ma co prawda mozliwosci na uzycie HTTP POST, ale lepszy rydz niz nic :)

no chyba, ze ktos zna lepszy pomysl? :)
Medyk 14 23 maja 2007, 18:21

Riddle to co było pod maską to już od ponad roku na wielu blogach było pisane (choć bardzo możliwe, że Twój artykuł jest pierwszym w rodzimym języku :)
To do czego się odniosłem w swoim komentarzu i czego mi brakuje w powyższym rozwiązaniu to bardziej przyjazne podejście do programisty js tj. nieinwazyjna łatka na implementacji js
[bwgg's journal] 15 31 maja 2007, 02:33

Riddle ratuje mi zad #1

Poprzez "Wykonywanie skryptów po załadowaniu DOM" ; )
shfx 16 10 czerwca 2007, 22:38

@mat: Aby wzbogacic dzialanie XMLHttpRequest o mozliwosc wysylania i pobierania danych z innych serwerow, uzywa sie tzw. proxy po stronie wlasnego serwera. Przeto serwer z serwerem kontaktowac sie moze =3, czy to przez API, czy tez np. przez Feed’a
mat 17 11 czerwca 2007, 23:49

@shfx: tak, tylko co zrobic, gdy nie mamy mozliwosci uruchomienia takiego proxy na serwerze? np. ze wzgledow bezpieczenstwa, tudziez z powodu zbyt wysokiego obciazenia? wtedy przydaje sie kazde wyjscie :)

btw. w trakcie prac nad standardem HTML 5 pojawila sie dyskusja nad wprowadzeniem XMLHttpRequest 2 w wersji cross-site :)
Dziudek's jogger 18 20 czerwca 2007, 20:26

Mootools 1.1 - Window.DomReady.js

Plik window.domready.js robi właściwie tylko jedno - dodaje nowe zdarzenie - domready. Na czym ono polega ? Jest ono wywoływane w momencie załadowania drzewa dokumentu - ma tą przewagę nad zdarzeniem onload, że z reguły ma miejsce szybciej b[...]
Skowron 19 10 września 2007, 12:14

„Ale za rozszerzanie Object przez prototype powinno się łapy twórcom Mootools obciąć. ;) Ale, ale! To na jeden z następnych wpisów, nie mogę się doczekać. ;>”

I ja również, może choć troszkę przybliżysz problem. Osobiście twierdzę że to fantastyczny pomysł. Czekam z niecierpliwością na wpis :)
Werbeagentur 20 07 grudnia 2007, 17:01

Thanks from Germany for share this great article
Krzysiek S. 21 18 stycznia 2008, 15:59

A czemu nie używać najprostrzego i nie wstawic sobie skryptu opdowiedzialnego na Domready na koniec dokumentu? Zaraz przed </body>. To napewno zadziała w kazdej przegladarce a te wszystkie sposoby nie dzialaja w 100%. Nie wiem od czego to zależy. Jak przegladam sobie irefoxem przyklady na jQuery to co chwila ktorys nie dziala bo $(window).ready(); nie zadzialalo.
Riddle 22 18 stycznia 2008, 16:01

Oddzielenie zachowania od struktury. JS w plikach HTML to amatorskie podejście. Jedyny wyjątek to dokumenty które mają po 100KB samego HTML i opóźnienie jest widoczne.
WebFocus 23 26 lipca 2009, 15:40

Skrócenie czasu ładowania stron WWW — optymalizacja skryptów JS

Ostatnio Webstop.pl rozpoczął serię artykułów związanych z internetowym know-how. Pierwszy z nich omawia różne sposoby na skrócenie czasu ładowania stron. A gra jest warta świeczki, bo dzisiejszy internauta jest bardzo niecierpliwy i szyb[...]