Browser Compatibility Issues

Browser compatibility includes style compatibility (CSS), interactive compatibility (javascript), browser hack

Style compatibility (1) Use Normalize. CSS to smooth out differences between browser styles, or customize your own reset. CSS. (2) Use the browser’s CSS compatible prefixes. In the development process, IDE development plug-in, CSS preprocessor and front-end automation construction project generally help us deal with the corresponding relationship between browser kernel and prefix as follows

The kernel mainly represents the browser prefix JS engine Trident IE browser - MS Gecko Firefox - Moz Presto Opera - O Webkit Chrome and Safari - Webkit V8Copy the code

Another filter property is supported in IE8 and earlier versions. Like: filter: Alpha (opacity = 50)

Browser kernel

A browser typically consists of the following resident threads:

  1. GUI rendering thread

Responsible for rendering browser interfaces, parsing HTML,CSS, building DOM trees and RenderObject trees, layout and drawing, etc

  1. JS engine thread (JS kernel)

Responsible for parsing Javascript scripts and running code

  1. Event trigger thread

Used to control the event loop

  1. Timing trigger thread

  2. Asynchronous HTTP request threads

Browser multi-process architecture

  1. Main process: responsible for the display and interaction of the browser interface. Manage each page, create and destroy other processes. Network resource management, download, etc
  2. Third-party plug-in process: Each type of plug-in corresponds to one process, which is created only when the plug-in is used.
  3. GPU process: used for 3D drawing
  4. The rendering process (also known as the browser kernel, which is multi-threaded internally and is responsible for page rendering, script execution, event handling, etc.)
    • Event trigger thread: When the corresponding event meets the trigger condition is triggered, the thread will add the event to the end of the queue to be processed, waiting for the JS engine to process
    • Timing trigger thread: the thread where setInterval and setTimeout reside
    • Asynchronous HTTP request threads
    • GUI rendering thread: responsible for rendering browser interfaces, parsing HTML,CSS, building DOM trees and RenderObject trees, layout and drawing, etc
    • JS engine threads: Also known as JS cores, are responsible for processing Javascript scripts

Note: GUI rendering threads and JavaScript engines are mutually exclusive

Browsers are multithreaded

JavaScript is single-threaded and does not conflict with asynchrony

  • Single thread of JS refers to a browser process with only one JS thread of execution, and only one piece of code is executing at a time
  • Asynchron is a mechanism in which two or more resident threads of the browser work together. For example, asynchronous requests are performed by both the JS execution thread and the event-firing thread

What blocks do CSS loads cause?

  • CSS does not block DOM parsing, but DOM rendering
  • CSS blocks JS execution, not JS file download

DOM and CSSOM are usually built in parallel, so CSS does not block DOM parsing. However, the Render tree relies on DOM tree and CSSOM Tree and does not start rendering until both are loaded, so CSS blocks DOM rendering

The JS file download is parallel to the CSS file download, and the stylesheet is loaded before the subsequent JS execution, so the CSS blocks the subsequent JS execution

JS blocks page loading?

JS blocks DOM parsing, which blocks the page

What is the difference between defer and Async?

With:

  • Both load external JS files asynchronously and do not block DOM parsing
  • Async is executed after the external JS is loaded and before the load event is triggered
  • Defer is executed after the JS has loaded, after the entire document has been parsed, and before the DOMContentLoaded event is triggered

Different: async means asynchronous

  • When the browser encounters an async script, the network request requesting the script is asynchronous and does not block the browser from parsing HTML. Once the network request returns, if the HTML is not fully parsed, the browser will pause parsing and let the JS engine execute the code first, and then parse the code
  • So the async is uncontrollable, out-of-order | the execution sequence between them is wholly dependent on the network transmission

defer means delay

  • When the browser encountered the defer script, the network request to obtain it was also asynchronous and did not block the browser from parsing the HTML. Once the network request came back, if the HTML was not parsed at this point, the browser would not pause parsing and execute the JS code, but wait for the HTML to be parsed before executing the JS code. That is, the script is delayed until the entire page has been parsed
  • If multiple defer script tags exist, the browser ensures that they are executed in the order they appear in the HTML, without breaking the dependencies between the JS scripts