jeena/en.javascript.info
1
0
Fork 0
Code Issues Pull requests Projects Packages Wiki Activity Actions

closes #513

Browse source
This commit is contained in:
Ilya Kantor 2018-10-07 21:10:16 +03:00
parent aa43deef3b
commit dac0e297f9
1 changed files with 10 additions and 8 deletions
Download patch file Download diff file Expand all files Collapse all files

18
2-ui/3-event-details/10-onload-ondomcontentloaded/article.md
View file

@ -55,7 +55,8 @@ External scripts (with `src`) also put DOM building to pause while the script is
The only exception are external scripts with `async` and `defer` attributes. They tell the browser to continue processing without waiting for the scripts. This lets the user see the page before scripts finish loading, which is good for performance. The only exception are external scripts with `async` and `defer` attributes. They tell the browser to continue processing without waiting for the scripts. This lets the user see the page before scripts finish loading, which is good for performance.
```smart header="A word about `async` and `defer`" ### Scripts with `async` and `defer`
Attributes `async` and `defer` work only for external scripts. They are ignored if there's no `src`. Attributes `async` and `defer` work only for external scripts. They are ignored if there's no `src`.
Both of them tell the browser that it may go on working with the page, and load the script "in background", then run the script when it loads. So the script doesn't block DOM building and page rendering. Both of them tell the browser that it may go on working with the page, and load the script "in background", then run the script when it loads. So the script doesn't block DOM building and page rendering.
@ -67,9 +68,9 @@ There are two differences between them.
| Order | Scripts with `async` execute *in the load-first order*. Their document order doesn't matter -- which loads first runs first. | Scripts with `defer` always execute *in the document order* (as they go in the document). | | Order | Scripts with `async` execute *in the load-first order*. Their document order doesn't matter -- which loads first runs first. | Scripts with `defer` always execute *in the document order* (as they go in the document). |
| `DOMContentLoaded` | Scripts with `async` may load and execute while the document has not yet been fully downloaded. That happens if scripts are small or cached, and the document is long enough. | Scripts with `defer` execute after the document is loaded and parsed (they wait if needed), right before `DOMContentLoaded`. | | `DOMContentLoaded` | Scripts with `async` may load and execute while the document has not yet been fully downloaded. That happens if scripts are small or cached, and the document is long enough. | Scripts with `defer` execute after the document is loaded and parsed (they wait if needed), right before `DOMContentLoaded`. |
So `async` is used for totally independent scripts. So `async` is used for independent scripts, like counters or ads, that don't need to access page content. And their relative execution order does not matter.
``` While `defer` is used for scripts that need DOM and/or their relative execution order is important.
### DOMContentLoaded and styles ### DOMContentLoaded and styles
@ -214,8 +215,8 @@ The typical output:
2. [2] readyState:interactive 2. [2] readyState:interactive
3. [2] DOMContentLoaded 3. [2] DOMContentLoaded
4. [3] iframe onload 4. [3] iframe onload
5. [4] readyState:complete 5. [4] img onload
6. [4] img onload 6. [4] readyState:complete
7. [4] window onload 7. [4] window onload
The numbers in square brackets denote the approximate time of when it happens. The real time is a bit greater, but events labeled with the same digit happen approximately at the same time (+- a few ms). The numbers in square brackets denote the approximate time of when it happens. The real time is a bit greater, but events labeled with the same digit happen approximately at the same time (+- a few ms).
@ -224,13 +225,14 @@ The numbers in square brackets denote the approximate time of when it happens. T
- `document.readyState` becomes `complete` when all resources (`iframe` and `img`) are loaded. Here we can see that it happens in about the same time as `img.onload` (`img` is the last resource) and `window.onload`. Switching to `complete` state means the same as `window.onload`. The difference is that `window.onload` always works after all other `load` handlers. - `document.readyState` becomes `complete` when all resources (`iframe` and `img`) are loaded. Here we can see that it happens in about the same time as `img.onload` (`img` is the last resource) and `window.onload`. Switching to `complete` state means the same as `window.onload`. The difference is that `window.onload` always works after all other `load` handlers.
## Summary ## Lifecycle events summary
Page lifecycle events: Page lifecycle events:
- `DOMContentLoaded` event triggers on `document` when DOM is ready. We can apply JavaScript to elements at this stage. - `DOMContentLoaded` event triggers on `document` when DOM is ready. We can apply JavaScript to elements at this stage.
- All scripts are executed except those that are external with `async` or `defer` - All inline scripts and scripts with `defer` are already executed.
- Images and other resources may still continue loading. - Async scripts may execute both before and after the event, depends on when they load.
- Images and other resources may also still continue loading.
- `load` event on `window` triggers when the page and all resources are loaded. We rarely use it, because there's usually no need to wait for so long. - `load` event on `window` triggers when the page and all resources are loaded. We rarely use it, because there's usually no need to wait for so long.
- `beforeunload` event on `window` triggers when the user wants to leave the page. If it returns a string, the browser shows a question whether the user really wants to leave or not. - `beforeunload` event on `window` triggers when the user wants to leave the page. If it returns a string, the browser shows a question whether the user really wants to leave or not.
- `unload` event on `window` triggers when the user is finally leaving, in the handler we can only do simple things that do not involve delays or asking a user. Because of that limitation, it's rarely used. - `unload` event on `window` triggers when the user is finally leaving, in the handler we can only do simple things that do not involve delays or asking a user. Because of that limitation, it's rarely used.