One important part of the Microsoft development cycle is to adjust the performance of the product. Performance tuning is one of the key components that developers should be mindful of. After years of development, the industry has a lot to learn about how to optimize the performance of WIN32 programs.
One of the problems developers now encounter is that it's not clear what causes DTHML and HTML pages to run fast or slow. Of course, there are some very simple ways-such as not to use 2MB large images. We've used other interesting techniques to improve the performance of DHTML pages, and hopefully they will help you improve your page performance.
Here I use an example of a program that creates a table. A table of 1000 rows (row) is created with the document.createelement () and Element.insertbefore () methods. Each row has one column (Cell). The cell contains content called "Text." How bad can this piece of code be? How much leeway can such a small procedure have? Please see the introduction.
At first I wrote a program that I thought would be quick, and I tried to avoid some low-level problems----like not explicitly defining variables, or using both VBScript and JavaScript in a single page. The procedure is as follows:
<body>
<script>
var tbl, Tbody, TR, TD, Text, I, Max;
max = 1000;
TBL = document.createelement ("TABLE");
Tbl.border = "1";
Tbody = document.createelement ("tbody");
Tbl.insertbefore (tbody, NULL);
Document.body.insertBefore (TBL, NULL);
For (i=0 i<max; i++) {
TR = document.createelement ("tr");
TD = Document.createelement ("TD");
Text = document.createTextNode ("text");
Td.insertbefore (text, NULL);
Tr.insertbefore (TD, NULL);
Tbody.insertbefore (tr, NULL);
}
</script>
</body>
Run this program on a PII233/64MB memory/nt4.0/ie5.0 machine. The page is loaded from the computer. From the start Load page to the page completely quiet (all events have been run, screen display completed) Time is 2328 milliseconds, which is also the baseline of this test (I call Test1).
In this page, a time-consuming operation is to frequently refer to global objects, such as "document", "Body", "window", and so on. Referencing all these similar global variables is far more expensive than referencing a local variable.
So I made the first improvement attempt: caching (cache) document.body to local variable "thebody":
Added the following code:
var thebody = document.body;
Then modify this line:
Document.body.insertBefore (TBL, NULL);
Replace it with the following:
Thebody.insertbefore (TBL, NULL);
View the second sample.
The change did not have much impact on the overall time, it shortened only 3 Ms. However, it has been shown that if there are document.body objects in the loop, the benefits will be considerable if they are modified by reference.
Subsequently, I cached the Document object----in our test, the Document object was referenced 3,002 times. The modified code is as follows:
<body>
<script>
var tbl, Tbody, TR, TD, Text, I, Max;
max = 1000;
var thedoc = document;
var thebody = thedoc.body;
TBL = Thedoc.createelement ("TABLE");
Tbl.border = "1";
Tbody = Thedoc.createelement ("tbody");
Tbl.insertbefore (tbody, NULL);
Thebody.insertbefore (TBL, NULL);
For (i=0 i<max; i++) {
TR = thedoc.createelement ("tr");
TD = Thedoc.createelement ("TD");
Text = Thedoc.createtextnode ("text");
Td.insertbefore (text, NULL);
Tr.insertbefore (TD, NULL);
Tbody.insertbefore (tr, NULL);
}
</script>
</body>
View the third sample.
The run time is only 2100ms, saving about 10% of the time. Using local variables instead of directly referencing the Document object saves an average of 0.4 milliseconds each time.
A common way to optimize performance is to set the "defer" property in the <SCRIPT> tab when the script does not need to run immediately. (The script is not included in a function block immediately, so it is executed during the load process.) When you set the Defer property, IE does not have to wait for the script to load and execute. This will make the page load faster. In general, this also means that the immediate script is best placed in a function block and processed in the onload handle of document or body object. It is useful to use this property when there are scripts that need to rely on user action----such as clicking a button, or moving the mouse over a range----. However, when some scripts need to be executed during page loading or after the load is completed, the benefits of using the defer property are not too great.
The following is a modified version of the code using the Defer property:
<body >
<script defer>
function init () {
var tbl, Tbody, TR, TD, Text, I, Max;
max = 1000;
var thedoc = document;
var thebody = thedoc.body;
TBL = Thedoc.createelement ("TABLE");
Tbl.border = "1";
Tbody = Thedoc.createelement ("tbody");
Tbl.insertbefore (tbody, NULL);
Thebody.insertbefore (TBL, NULL);
For (i=0 i<max; i++) {
TR = thedoc.createelement ("tr");
TD = Thedoc.createelement ("TD");
Text = Thedoc.createtextnode ("text");
Td.insertbefore (text, NULL);
Tr.insertbefore (TD, NULL);
Tbody.insertbefore (tr, NULL);
}
}
</script>
</body>
View the fourth sample.
The time for this test was 2043 Ms. The relative baseline test increased by 12%, up 2.5% from the last Test.
One of the improvements we're talking about here is very useful and, of course, a little bit cumbersome. When you need to create an element and then insert it into a tree structure, insert it directly into the trunk more efficiently----rather than inserting it into the large subtree first, and then inserting the large subtree into the trunk. For example, if you create a table with one column per row and some text in the column, you can do this:
1. Create <TR>
2. Create <TD>
3. Create Textnode Node
4. Insert Textnode into the <TD>
5. Insert <TD> into <TR>
6. Insert <TR> into tbody
When it is slower than the following method:
1. Create <TR>
2. Create <TD>
3. Create Textnode
4. Insert <TR> into tbody
5. Insert <TD> into <TR>
6. Insert Textnode into <TD>
The previous four tests were used in the first method. We used the latter method for the 5th time test. The code is as follows:
<body >
<script defer>
function init () {
var tbl, Tbody, TR, TD, Text, I, Max;
max = 1000;
var thedoc = document;
var thebody = thedoc.body;
TBL = Thedoc.createelement ("TABLE");
Tbl.border = "1";
Tbody = Thedoc.createelement ("tbody");
Tbl.insertbefore (tbody, NULL);
Thebody.insertbefore (TBL, NULL);
For (i=0 i<max; i++) {
TR = thedoc.createelement ("tr");
TD = Thedoc.createelement ("TD");
Text = Thedoc.createtextnode ("text");
Tbody.insertbefore (tr, NULL);
Tr.insertbefore (TD, NULL);
Td.insertbefore (text, NULL);
}
}
</script>
</body>
View the fifth sample.
TEST5 is only 1649ms. This was 25% higher than the last Test, almost 30% faster than the baseline.
The subsequent modifications were made using a prefabricated style sheet. Table columns with a prefab style sheet are wide or are set by the <COL> tab, and the width of each column is evenly spaced when there is no <COL> label. Because you do not need to recalculate the size of each column, using a style sheet actually improves performance, especially if there are many columns in the table.
The code to add style sheets (CSS) is very simple, as follows:
Tbl.style.tableLayout = "fixed";
View the sixth sample.
Because the table in our test has only one column, this change only improves the performance of page 1.6%. If there are more columns, the performance increase will be more.
The last two tests changed the way you inserted text into a table. In the previous test, we first created a textnode and then inserted it into the TD. In Test7, instead, we specify the contained text by InnerText. The modified code is:
Td.innertext = "Text";
View the seventh sample.
Surprisingly, the changes were very different----compared to the last 9% performance improvement, compared to a total increase of 36% performance. Time from the initial 2323ms to the last 1473ms.
Now, almost everyone knows that using element.innerhtml is very slow. To see exactly how slow it was, I did the last Test: Insert text using innerHTML instead of innertext. This greatly reduces performance. The time reached 3375ms, 80% slower than the last Test, and 45% slower than the baseline test. Obviously, innerHTML is very time-consuming.
Adjusting HTML page performance is similar to adjusting WIN32 application performance; you need to know what's slow and what's fast. Hopefully these methods will help you improve your page performance.
Start building with 50+ products and up to 12 months usage for Elastic Compute Service
1 on 1 presale consultation
24/7 Technical Support 6 Free Tickets per Quarter Faster Response
Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.
A comprehensive suite of global cloud computing services to power your business
Payment Methods We Support
