Document onload что делает

Страница: DOMContentLoaded, load, beforeunload, unload

У жизненного цикла HTML-страницы есть три важных события:

• DOMContentLoaded – браузер полностью загрузил HTML, было построено DOM-дерево, но внешние ресурсы, такие как картинки <img> и стили, могут быть ещё не загружены.
• load – браузер загрузил HTML и внешние ресурсы (картинки, стили и т.д.).
• beforeunload/unload – пользователь покидает страницу.

Каждое из этих событий может быть полезно:

• Событие DOMContentLoaded – DOM готов, так что обработчик может искать DOM-узлы и инициализировать интерфейс.
• Событие load – внешние ресурсы были загружены, стили применены, размеры картинок известны и т.д.
• Событие beforeunload – пользователь покидает страницу. Мы можем проверить, сохранил ли он изменения и спросить, на самом ли деле он хочет уйти.
• unload – пользователь почти ушёл, но мы всё ещё можем запустить некоторые операции, например, отправить статистику.

Давайте рассмотрим эти события подробнее.

DOMContentLoaded

Событие DOMContentLoaded срабатывает на объекте document .

Мы должны использовать addEventListener , чтобы поймать его:

В этом примере обработчик DOMContentLoaded запустится, когда документ загрузится, так что он увидит все элементы, включая расположенный ниже <img> .

Но он не дожидается, пока загрузится изображение. Поэтому alert покажет нулевой размер.

На первый взгляд событие DOMContentLoaded очень простое. DOM-дерево готово – получаем событие. Хотя тут есть несколько особенностей.

DOMContentLoaded и скрипты

Когда браузер обрабатывает HTML-документ и встречает тег <script> , он должен выполнить его перед тем, как продолжить строить DOM. Это делается на случай, если скрипт захочет изменить DOM или даже дописать в него ( document.write ), так что DOMContentLoaded должен подождать.

Поэтому DOMContentLoaded определённо случится после таких скриптов:

В примере выше мы сначала увидим «Библиотека загружена…», а затем «DOM готов!» (все скрипты выполнены).

Есть два исключения из этого правила:

1. Скрипты с атрибутом async , который мы рассмотрим немного позже, не блокируют DOMContentLoaded.
2. Скрипты, сгенерированные динамически при помощи document.createElement(‘script’) и затем добавленные на страницу, также не блокируют это событие.

DOMContentLoaded и стили

Внешние таблицы стилей не затрагивают DOM, поэтому DOMContentLoaded их не ждёт.

Но здесь есть подводный камень. Если после стилей у нас есть скрипт, то этот скрипт должен дождаться, пока загрузятся стили:

Причина в том, что скрипту может понадобиться получить координаты или другие свойства элементов, зависящих от стилей, как в примере выше. Естественно, он должен дождаться, пока стили загрузятся.

Так как DOMContentLoaded дожидается скриптов, то теперь он так же дожидается и стилей перед ними.

Встроенное в браузер автозаполнение

Firefox, Chrome и Opera автоматически заполняют поля при наступлении DOMContentLoaded .

Например, если на странице есть форма логина и пароля и браузер запомнил значения, то при наступлении DOMContentLoaded он попытается заполнить их (если получил разрешение от пользователя).

Так что, если DOMContentLoaded откладывается из-за долгой загрузки скриптов, в свою очередь – откладывается автозаполнение. Вы наверняка замечали, что на некоторых сайтах (если вы используете автозаполнение в браузере) поля логина и пароля не заполняются мгновенно, есть некоторая задержка до полной загрузки страницы. Это и есть ожидание события DOMContentLoaded .

window.onload

Событие load на объекте window наступает, когда загрузилась вся страница, включая стили, картинки и другие ресурсы. Это событие доступно через свойство onload .

В примере ниже правильно показаны размеры картинки, потому что window.onload дожидается всех изображений:

window.onunload

Когда посетитель покидает страницу, на объекте window генерируется событие unload . В этот момент стоит совершать простые действия, не требующие много времени, вроде закрытия связанных всплывающих окон.

Обычно здесь отсылают статистику.

Предположим, мы собрали данные о том, как используется страница: клики, прокрутка, просмотры областей страницы и так далее.

Естественно, событие unload – это тот момент, когда пользователь нас покидает и мы хотим сохранить эти данные.

Для этого существует специальный метод navigator.sendBeacon(url, data) , описанный в спецификации https://w3c.github.io/beacon/.

Он посылает данные в фоне. Переход к другой странице не задерживается: браузер покидает страницу, но всё равно выполняет sendBeacon .

Его можно использовать вот так:

• Отсылается POST-запрос.
• Мы можем послать не только строку, но так же формы и другие форматы, как описано в главе Fetch, но обычно это строковый объект.
• Размер данных ограничен 64 Кб.

К тому моменту, как sendBeacon завершится, браузер наверняка уже покинет страницу, так что возможности обработать ответ сервера не будет (для статистики он обычно пустой).

Для таких запросов с закрывающейся страницей есть специальный флаг keepalive в методе fetch для общих сетевых запросов. Вы можете найти больше информации в главе Fetch API.

Если мы хотим отменить переход на другую страницу, то здесь мы этого сделать не сможем. Но сможем в другом месте – в событии onbeforeunload .

window.onbeforeunload

Если посетитель собирается уйти со страницы или закрыть окно, обработчик beforeunload попросит дополнительное подтверждение.

Если мы отменим это событие, то браузер спросит посетителя, уверен ли он.

Вы можете попробовать это, запустив следующий код и затем перезагрузив страницу:

По историческим причинам возврат непустой строки так же считается отменой события. Когда-то браузеры использовали её в качестве сообщения, но, как указывает современная спецификация, они не должны этого делать.

Поведение было изменено, потому что некоторые веб-разработчики злоупотребляли этим обработчиком события, показывая вводящие в заблуждение и надоедливые сообщения. Так что, прямо сейчас старые браузеры всё ещё могут показывать строку как сообщение, но в остальных – нет возможности настроить показ сообщения пользователям.

readyState

Что произойдёт, если мы установим обработчик DOMContentLoaded после того, как документ загрузился?

Естественно, он никогда не запустится.

Есть случаи, когда мы не уверены, готов документ или нет. Мы бы хотели, чтобы наша функция исполнилась, когда DOM загрузился, будь то сейчас или позже.

Свойство document.readyState показывает нам текущее состояние загрузки.

Есть три возможных значения:

• "loading" – документ загружается.
• "interactive" – документ был полностью прочитан.
• "complete" – документ был полностью прочитан и все ресурсы (такие как изображения) были тоже загружены.

Так что мы можем проверить document.readyState и, либо установить обработчик, либо, если документ готов, выполнить код сразу же.

Например, вот так:

Также есть событие readystatechange , которое генерируется при изменении состояния, так что мы можем вывести все эти состояния таким образом:

Событие readystatechange – альтернативный вариант отслеживания состояния загрузки документа, который появился очень давно. На сегодняшний день он используется редко.

Для полноты картины давайте посмотрим на весь поток событий:

Здесь документ с <iframe> , <img> и обработчиками, которые логируют события:

Рабочий пример есть в песочнице.

1. [1] начальный readyState:loading
2. [2] readyState:interactive
3. [2] DOMContentLoaded
4. [3] iframe onload
5. [4] img onload
6. [4] readyState:complete
7. [4] window onload

Цифры в квадратных скобках обозначают примерное время события. События, отмеченные одинаковой цифрой, произойдут примерно в одно и то же время (± несколько миллисекунд).

Resource loading: onload and onerror

The browser allows us to track the loading of external resources – scripts, iframes, pictures and so on.

There are two events for it:

• onload – successful load,
• onerror – an error occurred.

Loading a script

Let’s say we need to load a third-party script and call a function that resides there.

We can load it dynamically, like this:

…But how to run the function that is declared inside that script? We need to wait until the script loads, and only then we can call it.

For our own scripts we could use JavaScript modules here, but they are not widely adopted by third-party libraries.

script.onload

The main helper is the load event. It triggers after the script was loaded and executed.

So in onload we can use script variables, run functions etc.

…And what if the loading failed? For instance, there’s no such script (error 404) or the server is down (unavailable).

script.onerror

Errors that occur during the loading of the script can be tracked in an error event.

For instance, let’s request a script that doesn’t exist:

Please note that we can’t get HTTP error details here. We don’t know if it was an error 404 or 500 or something else. Just that the loading failed.

Events onload / onerror track only the loading itself.

Errors that may occur during script processing and execution are out of scope for these events. That is: if a script loaded successfully, then onload triggers, even if it has programming errors in it. To track script errors, one can use window.onerror global handler.

Other resources

The load and error events also work for other resources, basically for any resource that has an external src .

There are some notes though:

• Most resources start loading when they are added to the document. But <img> is an exception. It starts loading when it gets a src (*) .
• For <iframe> , the iframe.onload event triggers when the iframe loading finished, both for successful load and in case of an error.

That’s for historical reasons.

Crossorigin policy

There’s a rule: scripts from one site can’t access contents of the other site. So, e.g. a script at https://facebook.com can’t read the user’s mailbox at https://gmail.com .

Or, to be more precise, one origin (domain/port/protocol triplet) can’t access the content from another one. So even if we have a subdomain, or just another port, these are different origins with no access to each other.

This rule also affects resources from other domains.

If we’re using a script from another domain, and there’s an error in it, we can’t get error details.

For example, let’s take a script error.js that consists of a single (bad) function call:

Now load it from the same site where it’s located:

We can see a good error report, like this:

Now let’s load the same script from another domain:

The report is different, like this:

Details may vary depending on the browser, but the idea is the same: any information about the internals of a script, including error stack traces, is hidden. Exactly because it’s from another domain.

Why do we need error details?

There are many services (and we can build our own) that listen for global errors using window.onerror , save errors and provide an interface to access and analyze them. That’s great, as we can see real errors, triggered by our users. But if a script comes from another origin, then there’s not much information about errors in it, as we’ve just seen.

Similar cross-origin policy (CORS) is enforced for other types of resources as well.

To allow cross-origin access, the <script> tag needs to have the crossorigin attribute, plus the remote server must provide special headers.

There are three levels of cross-origin access:

1. No crossorigin attribute – access prohibited.
2. crossorigin="anonymous" – access allowed if the server responds with the header Access-Control-Allow-Origin with * or our origin. Browser does not send authorization information and cookies to remote server.
3. crossorigin="use-credentials" – access allowed if the server sends back the header Access-Control-Allow-Origin with our origin and Access-Control-Allow-Credentials: true . Browser sends authorization information and cookies to remote server.

You can read more about cross-origin access in the chapter Fetch: Cross-Origin Requests. It describes the fetch method for network requests, but the policy is exactly the same.

Such thing as “cookies” is out of our current scope, but you can read about them in the chapter Cookies, document.cookie.

In our case, we didn’t have any crossorigin attribute. So the cross-origin access was prohibited. Let’s add it.

We can choose between "anonymous" (no cookies sent, one server-side header needed) and "use-credentials" (sends cookies too, two server-side headers needed).

If we don’t care about cookies, then "anonymous" is the way to go:

Now, assuming that the server provides an Access-Control-Allow-Origin header, everything’s fine. We have the full error report.

Summary

Images <img> , external styles, scripts and other resources provide load and error events to track their loading:

• load triggers on a successful load,
• error triggers on a failed load.

The only exception is <iframe> : for historical reasons it always triggers load , for any load completion, even if the page is not found.

The readystatechange event also works for resources, but is rarely used, because load/error events are simpler.

Tasks

Load images with a callback

Normally, images are loaded when they are created. So when we add <img> to the page, the user does not see the picture immediately. The browser needs to load it first.

To show an image immediately, we can create it “in advance”, like this:

The browser starts loading the image and remembers it in the cache. Later, when the same image appears in the document (no matter how), it shows up immediately.

Create a function preloadImages(sources, callback) that loads all images from the array sources and, when ready, runs callback .

For instance, this will show an alert after the images are loaded:

In case of an error, the function should still assume the picture “loaded”.

In other words, the callback is executed when all images are either loaded or errored out.

The function is useful, for instance, when we plan to show a gallery with many scrollable images, and want to be sure that all images are loaded.

In the source document you can find links to test images, and also the code to check whether they are loaded or not. It should output 300 .

Name already in use

javascript-tutorial-ru / 2-ui / 3-event-details / 10-onload-ondomcontentloaded / article.md

• Go to file T
• Go to line L
• Copy path
• Copy permalink

• Open with Desktop
• View raw
• Copy raw contents Copy raw contents

Copy raw contents

Copy raw contents

Загрузка документа: DOMContentLoaded, load, beforeunload, unload

Процесс загрузки HTML-документа, условно, состоит из трёх стадий:

• DOMContentLoaded — браузер полностью загрузил HTML и построил DOM-дерево.
• load — браузер загрузил все ресурсы.
• beforeunload/unload — уход со страницы.

Все эти стадии очень важны. На каждую можно повесить обработчик, чтобы совершить полезные действия:

• DOMContentLoaded — означает, что все DOM-элементы разметки уже созданы, можно их искать, вешать обработчики, создавать интерфейс, но при этом, возможно, ещё не догрузились какие-то картинки или стили.
• load — страница и все ресурсы загружены, используется редко, обычно нет нужды ждать этого момента.
• beforeunload/unload — можно проверить, сохранил ли посетитель изменения, уточнить, действительно ли он хочет покинуть страницу.

Далее мы рассмотрим важные детали этих событий.

Событие DOMContentLoaded происходит на document и поддерживается во всех браузерах, кроме IE8-. Про поддержку аналогичного функционала в старых IE мы поговорим в конце главы.

Обработчик на него вешается только через addEventListener :

В примере выше обработчик DOMContentLoaded сработает сразу после загрузки документа, не дожидаясь получения картинки.

Поэтому на момент вывода alert и сама картинка будет невидна и её размеры — неизвестны (кроме случая, когда картинка взята из кеша браузера).

В своей сути, событие onDOMContentLoaded — простое, как пробка. Полностью создано DOM-дерево — и вот событие. Но с ним связан ряд существенных тонкостей.

DOMContentLoaded и скрипты

Если в документе есть теги <script> , то браузер обязан их выполнить до того, как построит DOM. Поэтому событие DOMContentLoaded ждёт загрузки и выполнения таких скриптов.

Исключением являются скрипты с атрибутами async и defer , которые подгружаются асинхронно.

Побочный эффект: если на странице подключается скрипт с внешнего ресурса (к примеру, реклама), и он тормозит, то событие DOMContentLoaded и связанные с ним действия могут сильно задержаться.

Современные системы рекламы используют атрибут async , либо вставляют скрипты через DOM: document.createElement(‘script’). , что работает так же как async : такой скрипт выполняется полностью независимо от страницы и от других скриптов — сам ничего не ждёт и ничего не блокирует.

DOMContentLoaded и стили

Внешние стили никак не влияют на событие DOMContentLoaded . Но есть один нюанс.

Если после стиля идёт скрипт, то этот скрипт обязан дождаться, пока стиль загрузится:

Такое поведение прописано в стандарте. Его причина — скрипт может захотеть получить информацию со страницы, зависящую от стилей, например, ширину элемента, и поэтому обязан дождаться загрузки style.css .

Побочный эффект — так как событие DOMContentLoaded будет ждать выполнения скрипта, то оно подождёт и загрузки стилей, которые идут перед <script> .

Firefox/Chrome/Opera автозаполняют формы по DOMContentLoaded .

Это означает, что если на странице есть форма для ввода логина-пароля, то браузер введёт в неё запомненные значения только по DOMContentLoaded .

Побочный эффект: если DOMContentLoaded ожидает множества скриптов и стилей, то автозаполнение не сработает до полной их загрузки.

Конечно, это довод в пользу того, чтобы не задерживать DOMContentLoaded , в частности — использовать у скриптов атрибуты async и defer .

Событие onload на window срабатывает, когда загружается вся страница, включая ресурсы на ней — стили, картинки, ифреймы и т.п.

Пример ниже выведет alert лишь после полной загрузки окна, включая IFRAME и картинку:

Когда человек уходит со страницы или закрывает окно, на window срабатывает событие unload . В нём можно сделать что-то, не требующее ожидания, например, закрыть вспомогательные popup-окна, но отменить сам переход нельзя.

Это позволяет другое событие — onbeforeunload , которое поэтому используется гораздо чаще.

Если посетитель инициировал переход на другую страницу или нажал «закрыть окно», то обработчик onbeforeunload может приостановить процесс и спросить подтверждение.

Для этого ему нужно вернуть строку. По историческим причинам некоторые браузеры покажут ее, но большинство – стандартное сообщение.

Эмуляция DOMContentLoaded для IE8-

Прежде чем что-то эмулировать, заметим, что альтернативой событию onDOMContentLoaded является вызов функции init из скрипта в самом конце BODY , когда основная часть DOM уже готова:

Причина, по которой обычно предпочитают именно событие — одна: удобство. Вешается обработчик и не надо ничего писать в конец BODY .

Если вы всё же хотите использовать onDOMContentLoaded кросс-браузерно, то нужно либо подключить какой-нибудь фреймворк — почти все предоставляют такой функционал, либо использовать функцию из мини-библиотеки jquery.documentReady.js.

Несмотря на то, что в названии содержится слово «jquery», эта библиотечка не требует jQuery. Наоборот, она представляет собой единственную функцию с названием $ , вызов которой $(callback) добавляет обработчик callback на DOMContentLoaded (можно вызывать много раз), либо, если документ уже загружен — выполняет его тут же.

Здесь alert сработает до загрузки картинки, но после создания DOM, в частности, после появления текста. И так будет для всех браузеров, включая даже очень старые IE.

««smart header Технически, эмуляция `DOMContentLoaded` для старых IE осуществляется очень забавно.

Основной приём — это попытка прокрутить документ вызовом:

Метод doScroll работает только в IE и «методом тыка» было обнаружено, что он бросает исключение, если DOM не полностью создан.

Поэтому библиотека пытается вызвать прокрутку, если не получается — через setTimeout(. 1) пытается прокрутить его ещё раз, и так до тех пор, пока действие не перестанет вызывать ошибку. На этом этапе документ считается загрузившимся.

Внутри фреймов и в очень старых браузерах такой подход может ошибаться, поэтому дополнительно ставится резервный обработчик на onload , чтобы уж точно сработал.

JavaScript onload

The onload in Javascript is responsible for loading objects within a web page, it occurs when the web page is loaded and needs the loading of other important elements. The onload in javascript is compatible with loading elements like CSS files, images, script files, etc. within a web page. The onload events are one of the most used and primarily part of the <body> tag. Another advantage is the ability of the onload event to deal with web cookies. One of the practical use of onload method is letting the onload event read and verify the browser details before loading the web page.

Every time a web page is loaded, there are a number of elements and events happening in the background, loading a number of objects and frames. The process of loading these web page elements is important as they carry the data.

Web development, programming languages, Software testing & others

Syntax

There are very few methods and functions with multiple syntaxes. The onload has three main ways to implement and respective syntaxes The standard syntax for onload to implement within javascript is as follows:

Explanation: The above syntax is a basic way to implement the onload event within a javascript file. It starts with an object, any object, according to the need. Followed by the onload keyword, you will notice it is passed with a dot between, meaning the object extends the onload event. Then we have our function, as per our needs, followed by a script to be executed.

onload in HTML

The syntax for onload in HTML works with the brackets as any other tag. Syntax is as follows:

Explanation: Within the brackets, goes our element, which we can say is an element like an image or another script for CSS or Javascript.

And the third syntax for the onload is somewhat improvement of the javascript syntax, it is as follows:

Explanation: Similar to the basic syntax, it starts with an object followed by the event listener, and within the bracket, go our load keyword and the script, or the element to be loaded.

How does onload Event work in JavaScript?

The onload function works as an event handler for all the objects that are to be loaded on a web page. This window. onload proper is a default part of the browser. The onload function is responsible for loading the entire web page, all its scripts, and components.

It is called onload for the reason that it loads the web page and its components, before the functions. That is why it can also be called an event handler as it manages the entire web page. Now that we have understood what onload is and its syntax, let’s implement it.

Examples to Implement JavaScript onload

Below are some examples of onload event:

Example #1

For our very first example, we will implement the onload function in Javascript script, within an html web page:

Code:

Output:

Explanation: Started with all required tags for the HTML web page, then we have our body tag, within body our first paragraph, that prints a simple message as proof of well-executed code. Then we have our iframe, which has an id of samFrame and then the source to the image file that we intend to load within this frame. The image source is followed by height and width. Then we have another paragraph that simply hold the id for code. Then our script begins, with the important tag as a document along with getting element by id. For id, we have passed our image iframe id. Then connected is our onload event, which calls for the function and the script. Towards the end, we have another function, which simply goes by the id that we defined earlier and prints a simple message of Iframe loading. At last, we have all our tags to an end.

Example #2

Now, our first example has been executed, where we used onload within javascript. For our next example, we have implemented the HTML type syntax, in a normal web page. The code is as follows:

Code:

Output:

After the alert is displayed, when we click on the OK button, the image that we intend to load in a web page is loaded, as shown in the below image.

Explanation: Started with a DOCTYPE HTML tag, stating the beginning of the web page code. Then we have our HTML and body tags started, with the intention of having our image loaded in the middle of the web page we use the center tag. Then our onload statement starts with a source for the image that we intend to load, followed by the onload keyword which points towards the loadIma function. Then we have our width and height mentioned as per our needs. Ending the center tag, we begin with a script tag, which holds the function loadIma. This function calls for an alert, which will be displayed once the image is loaded. Finally, end for all our tags.

Conclusion

Every web page loads the number of events and objects, onload is responsible for loading these objects. The onload works with HTML and javascript, it can be passed in HTML tag as well as a script. The onload can load images, CSS files, and any script files within a web page, as per needs. Moreover, the onload deals with web cookies too.

Recommended Articles

This is a guide to JavaScript onload. Here we discuss an introduction to JavaScript onload, syntax, how does it work, and examples with code and output. You can also go through our other related articles to learn more –