I saw an article he wrote last year on Perfection kills. It was very detailed about HTML optimization. I will record it for now, although some of the things in it cannot be applied in the current environment. Under the current trend of WEB applications gradually becoming front-end, client-side optimization has attracted more and more attention. How to reduce code, how to quickly display applications to users, how to reduce user waiting time, etc., such as Yahoo's 34 golden rules of optimization A detailed optimization plan is proposed.
The most basic part of web page optimization should be HTML optimization. Specifically, the first is markup cleaning. Cleaning markup can not only reduce the size of the document, but also make the document easier to maintain and improve the visibility of search engines (Clean markup means better accessibility) , easier maintenance, and good search engine visibility), but even for those web pages that are said to be highly optimized, if you look closely at the code, you can still find many tag usages that can be deleted or are outdated:
1.Comment characters in script
<SCRIPT language=javascript>
<!-- Begin
alert("daimaren.cn");
// End -->
</script>
Unless an almost extinct browser like 95 Netscape 1.0 requires such processing, in most mainstream browsers, adding HTML comments to script blocks is completely unnecessary.
2.<![CDATA[ … ]>
<script type="text/javascript">
//<![CDATA[
...
//]]>
</script>
This is another error prevention measure that is often added to js code blocks when dealing with real XHTML documents ("application/xhtml+xml" content-type) to prevent the code from parsing a < symbol as the beginning of a tag. , all content contained in CDATA will be treated as text. But the actual situation is that the content-type of almost all web pages at present is text/html, which means that they are not xml documents in the strict sense, but just text text, so this error prevention measure is completely unnecessary. Even if you are sure to support xml documents, you should use CDATA appropriately depending on the situation.
3.onclick=”…”, onmouseover=”“and so on.
It is a very unwise practice to write event attributes in HTML tags, which reduces the maintainability of the code and pollutes the tags. If the event attributes are dynamically added through JS, not only can it be flexibly controlled, but also the JS client can be used The advantage of caching is that these event attributes do not have to follow every document request.
4.onclick=”javascript:…”
This is an interesting javascript mess. Pseudo-protocols and intrinsic event handlers can make up to 100,000 redundant combinations. The fact is that the content inside the event attribute becomes a fucution of the body after parsing. This function will then serve as the event handler. , so javascript: becomes a useless redundant tag here.
5.href=”javascript:void(0)”
Continuing with the javascript: pseudo-protocol, one of the notorious ones is javascript:void(0), which is used to avoid the default anchor action. It will cause JS to fail to parse normally or make errors (disabled/not available/errors). The anchor point is completely unavailable. The ideal solution is to fill in the correct URL in the href, and then use JS to dynamically rewrite it, so that the anchor point will not be unavailable even if the JS is not executed. HREF=“#” is a streamlined and faster alternative.
6. style=”…”
There is no essential error, but it is troublesome to maintain later. In addition, moving it to an external CSS file can be cached to improve page execution efficiency.
7. <script language=”Javascript” … >
One of the most misunderstood attributes, thinking that this is the "language" of the script, is so old that it was deprecated in 1999.
8. <script charset=”…” … >
<script type="text/javascript" charset="UTF-8">
...
</script>
Another easily misunderstood attribute of the script tag, charset is described in HTML4.01: Please note that the charset attribute refers to the script encoding specified by the src attribute of the character, and it does not involve the content of the script element. (Note that the charset attribute refers to the character encoding of the script designated by the src attribute; it does not concern the content of the SCRIPT element.), that is to say, he only specifies the encoding format of the script file when outlining the script. Not recommended.