Differences between different kernel browsers and browser rendering (GO)

First, a brief introduction to what is the browser kernel.


The most important or core part of the browser is "Rendering engine", which can be translated into "interpretation engines", but we are generally used to call it "browser kernel". Responsible for interpreting Web page syntax (such as HTML, JavaScript) and rendering (displaying) Web pages. So the so-called browser kernel is the rendering engine used by the browser, and the rendering engine determines how the browser displays the contents of the page and the formatting information of the page. Different browser cores have different interpretations of the syntax of the Web page, so the rendering (display) effect of the same page in different kernel browsers may be different, which is why the Web page writer needs to test the display of the page in different kernel browsers.

There are many browser cores, if you add all the non-commercial free core that almost no one is using, then there may be about 10 or more, but usually we have only about four of the following, let's introduce briefly below. Trident:ie Browser uses the kernel, the kernel program was first adopted in the 1997 IE4, is Microsoft on the basis of mosaic code to repair
Changed, and used to the present IE9. Trident is actually an open kernel, its interface core design is quite mature, so there are many
Browsers that use the IE kernel instead of IE are emerging (such as Maxthon, the world, TT, Greenbrowser, Avantbrowser, etc.). In addition
For convenience there are a lot of people directly referred to as IE kernel (of course, do not exclude some people because they do not know the kernel name and have to say so). Because IE itself "monopoly" (although nominally IE is not a monopoly, but in fact, especially from the Windows 95 to the beginning of the XP, in terms of market share, ie indeed with the use of Windows Dongfeng in the "monopoly" status) and make the Trident core of the long-term a single big, Microsoft has not updated the Trident kernel for a long time, which leads to two consequences-one is that the Trident kernel was almost out of touch with the Standard (2005), the second is the Trident kernel of a large number of bugs and other security issues are not resolved in a timely manner, Then add some developers who are committed to open source and some scholars to open their view that Internet Explorer is unsafe, there are many users to other browsers, Firefox and Opera is the rise of this time. The significant increase in the market share of non-Trident kernel browsers has also led many web developers to pay attention to web standards and non-IE browser browsing effects. Gecko:netscape6 began to adopt the kernel, the later Mozilla Firefox (Firefox) also adopted the core, Gecko features
Is that the code is completely public, so it can be developed so that programmers around the world can write code for it and add functionality. Because it's an open source.
Kernel, so favored by many people, Gecko Kernel browser is also a lot, this is also geckos core although young but market share can quickly
Important reasons for the improvement. In fact, the origin of the Gecko engine is not unrelated to ie, previously said IE did not use the standard, which led to a number of Microsoft internal development staff dissatisfaction; they started Mozilla with some of the Netscape employees who had stopped updating. Based on the mosaic kernel at the time
Rewrite the kernel, then developed the geckos. In fact, the browser of the Gecko kernel still has the most Firefox (Firefox) users,
So sometimes it is called the Firefox kernel. Gecko is also a cross-platform kernel that can be used in Windows, BSD, Linux and Mac OS X
Used in the. Presto: The kernel currently used by opera, which was first used in the 2003 Opera7, features the ultimate in rendering speed optimization, and is now recognized as the fastest browser core for web browsing, but at the expense of Web compatibility.

In fact, this is a dynamic kernel, the biggest difference with the previous several kernels on the script processing, Presto has a natural advantage, the page can be all or part of the response to the script event, such as in the case of re-parsing.

In addition, the kernel has the fastest speed when executing the javascrīpt, according to the test under the same conditions, the Presto kernel performs equivalent javascrīpt only about gecko of Trident and 1/3 cores (the Trident kernel is the slowest, However, there is not much difference between the two.
The test did not test the WebCore kernel because of the different hardware conditions of the Apple machine and the normal PC. Unfortunately Presto is a commercial engine, the use of Presto except opera, only the Ndsbrowser, Wii Internet Channle, Nokia 770 Web browser, etc., which greatly limits the development of Presto. Webkit: Apple's own kernel, which is also the kernel used by Apple's Safari browser. The WebKit engine includes the WebCore typesetting engine and the JavaScriptCore parsing engine, all derived from KDE's khtml and KJS engines, which are free software, licensed under the GPL, and supporting the development of BSD systems.
So WebKit is also free software, while open source code. In terms of security is not affected by IE, Firefox, so Safari browser is still very safe at home.

Limited to the use of Mac OS X is not widespread and Safari has been just Mac OS X's exclusive browser, the kernel itself should say the market is not large, but it seems that according to the latest browser survey shows that the browser market has even surpassed Opera's Presto- This, of course, is due to the popularity of Apple's move to the x86 architecture, and the fact that Safari 3 has finally launched the Windows edition.

There are also popular browsers such as OmniWeb, Shiira and so on under Mac.

Google Chrome also uses WebKit as the kernel.

The WebKit kernel is also widely used on mobile phones, such as Google's phone Gphone, Apple's IPhone, and the browser kernel engine used by Nokia's Series browser, all based on WebKit. Second, the browser rendering principle (http://hi.baidu.com/zhoumm1008/blog/item/03fa88f97fe5ddebfd037f4b.html)

Web pages run in a wide variety of browsers, and the speed with which the browser loads and renders the page directly affects the user experience. Simply put, page rendering is the process by which the browser displays HTML code in a browser window based on CSS-defined rules. Let's get a glimpse of how browsers work:
1. The user enters the URL (assuming it is an HTML page, and is the first access), the browser makes a request to the server, the server returns the HTML file;
2. The browser starts loading the HTML code, and the discovery 3. The browser also issued a request for CSS files, the server returned the CSS file;
4. The browser continues to load the HTML <body> part of the code, and the CSS file has been handed, you can start to render the page;
5. The browser finds a tag in the code that refers to a picture that makes a request to the server. At this point the browser will not wait until the picture is finished downloading, but continue to render the following code;
6. The server returns a picture file, because the picture occupies a certain area, affecting the layout of the following paragraphs, so the browser needs to return to re-render this part of the code;
7. The browser found a <script> tag containing a line of JavaScript code, run it quickly;
8. The JavaScript script executes this statement, which commands the browser to hide the code from a

(style.display= "None"). The cup has, suddenly missing such an element, the browser has to re-render this part of the code;
9. Finally the arrival of 10. And so on, the user points the "skin" button in the interface, JavaScript lets the browser change the CSS path of the <link> tag;
11. The browser summoned all the people here <span><ul><li>, "Everybody pack up, we have to start over ...", the browser to the server please
Request a new CSS file and re-render the page.

The browser runs back and forth every day, knowing that the quality of the HTML and CSS code written by different people is uneven, and that one day you might run and run and hang up. Fortunately, there are such a group of people in the world- page refactoring engineer , usually very inconspicuous, but also to help the visual designers to change the word, actually secretly or do a lot of practical.

Speaking of why the page is slow? That's because the browser takes the time and effort to render, especially when it finds that some part of the change has affected the layout and needs to be re-rendered , which the insiders call the process called reflow.

the reflow is almost unavoidable. Now some of the popular effects on the interface, such as the collapse of the tree directory, the expansion (essentially the display and hiding of elements), will cause the browser reflow. Mouse slide over, click ... As long as these behaviors are causing the changes in the placeholder area, positioning mode, margin and other properties of some elements on the page, it will cause the re-rendering of the interior, surrounding and even the entire page. Usually we can't predict what part of the code the browser will reflow, and they all affect each other.

　　the reflow problem can be optimized and we can minimize unnecessary reflow. For example, in the beginning of the picture loading problem, this is actually an avoidable reflow--to the picture to set the width and height on it. This allows the browser to know the placeholder area of the image, reserving the location before loading the image.

In addition, there is a term similar to reflow look:repaint, Chinese is called redraw . If you just change the background color of an element, the text color, the border color, and so on, it doesn't affect the properties of its surrounding or interior layout, it will only cause the browser to repaint. Repaint speed is significantly faster than reflow (in IE need to change the argument, reflow more slowly than repaint).

Third, from the browser's rendering principle of CSS performance (http://hi.baidu.com/zhoumm1008/blog/item/03fa88f97fe5ddebfd037f4b.html)

Usually we are dealing with the browser almost every day, the page written out is likely to be displayed in different browsers. Bitter front-end siege division to be compatible with each browser and constantly testing and debugging, but also in the brain to write down all kinds of bugs and solutions encountered, and we do not seem to take the initiative to focus on and understand how the browser works. If we do a little bit of this, I want to be able to avoid some problems and improve the performance of the page in the process of the project. Today we mainly based on the browser's rendering principle of the performance of the CSS to make a little improvement (of course, JS This article temporarily does not consider, the following article will do introduction), let us together to uncover the browser's rendering principle of this mysterious veil:

Ultimately, the difference between the page effects that the browser shows is that the rendering engine, Rendering engine (also known as the typesetting engines), is what we usually call the "browser kernel", responsible for parsing page syntax (such as HTML, JavaScript) and rendering, Display Web pages. The same code in different browsers renders the effect is not the same, then it is likely that different browser kernel caused.

Let's look at the specific workflow of the browser when loading the page (figure I):

(Figure I)

1. Parsing HTML to reconstruct the DOM tree (parsing HTML to construct the DOM trees): The rendering engine begins parsing the HTML document, converting the tags in the tree to the DOM node, which is called the "content tree".

2. Build the render tree (construction): Parse the CSS (including external CSS files and style elements), calculate the style of the node based on the CSS selector, create another tree-the rendering tree.

3. Layout of the render tree: recursive invocation from the root node, calculate the size and position of each element, and give the exact coordinates that each node should appear on the screen.

4. Draw the render tree (Painting the render tree): traverse the render trees, and each node will be drawn using the UI back-end layer.

The main process is to build a DOM tree where the elements of the page will be created into the DOM tree, and whenever a new element is added to the DOM tree, the browser will look through the CSS stylesheet through the CSS engine and find a style rule that matches that element.

Note: The CSS engine looks up the style sheet and matches each rule in a right-to-left order. See the following rules:

1	#nav Li {}

It looks pretty fast, actually very slow, although it's a little confusing #_#. Most of us, especially those who read from left to right, may guess that the browser is also performing a left-to-right matching rule, so it is assumed that this rule is not expensive. In my mind, we imagined that the browser would work like this: Find the only element with the ID nav, and then apply that style to the LI element of the immediate child element. We know that there is an element with an ID of NAV, and it has only a few Li child elements, so this CSS selector should be quite efficient.

In fact, CSS selectors are matched from right to left. Knowing this knowledge, we know that before this seemingly efficient rule actually costs quite high, the browser must traverse each Li element on the page and determine whether the ID of its parent element is NAV.

1

*{}

Well, this method I just wrote CSS also wrote, but this efficiency is poor to the extreme approach, because the * wildcard will match all elements, so the browser must go through each element, so the number of times may be tens of thousands!

1	ul#nav{} ul.nav{}

A specified ID in the page can only correspond to one element, so there is no need to add additional qualifiers, and this makes it less efficient. Also do not qualify the class selector with a specific tag, but rather extend the class name according to the actual situation. For example, change Ul.nav to. Main_nav better.

1	Ul Li Li li. nav_item{}

For a selector like this, it has been written before, and at the end of the number of descendant selectors, why not use a class to correlate the last tag element, such as. Extra_navitem, which only needs to match the class-extra_navitem element, which significantly improves the efficiency

For this, in the CSS writing process, summed up the following performance improvement scenarios:

1. avoid using wildcard rules such as *{} to calculate an astonishing number of times! Select only the elements that need to be used
2. As little as possible to choose the label, but with class such as: #nav li{}, you can add Nav_item class name for Li, the following selection. nav_item{}
3. do not use tags to qualify the id or class selector such as: Ul#nav, should be simplified to #nav
4. minimize the use of descendant selectors, lower the weight of the selector the cost of the descendant selector is the highest, try to minimize the depth of the selector, not more than three layers, and more use the class to correlate each tag element
5. consider inheritance to understand which properties can be inherited, and then avoid repeating the rules for those properties

The use of efficient selectors, you can reduce the page rendering time, so as to effectively improve the user experience (the faster the page, the user of course, the more like ^_^), you can look at the CSS selectors test, the focus of this experiment is to evaluate the cost of complex selectors and simple selectors. Perhaps when you want the rendering speed to be the most efficient, you might configure an ID for each individual tag, and then write the style with those IDs. That would be super fast and super ridiculous! The result is a very poor semantics, and later maintenance is hard to get to the extreme.

But after all, CSS performance is something that may be really minimal for small projects, and ascension may not be obvious, but it can be helpful for large projects. And a good CSS writing habits and methods can help us more rigorous requirements for themselves.

Differences between different kernel browsers and browser rendering (GO)