HTML5 web worker is used to solve some stubborn problems of resource pre-loading.

Sometimes, in order to access the next page, it can be faster. We may pre-load the next page and related resources using idle space after the onload of the current page. In order not to affect the current page, we must ensure that these pre-loaded html css js resources are not parsed or executed.   Let's take a look at some other options: New image (). SRC: the disadvantage is that only the complete mimetype pre-load is the image/* resource. Other resources will only be loaded with the data of one package. The download will be terminated.   LINK rel = "stylesheet" disadvantage: the CSS style of the ie css expression will be rendered. onload onerror cannot be known for non-ie LINK rel = "stylesheet" Disabled = "disabled"... do not render CSS preload. But FF may be invalid. Unless additional attributes are configured. LINK rel = "stylesheet" Media = "cache etc..." not rendering CSS disadvantages non-ie No onload onerror, ie will trigger a draw rendering page   LINK rel = "alternate stylesheet" does not render CSS. Disadvantages: Non-ie, no onload onerror. ie will trigger a draw rendering page. LINK rel = "prefetch" disadvantages gecko browsers support ff1.5 +. the link node cannot be dynamically added. the advantage is automatically in the window. load the resource only after the onload. other functions such as font-face background-image do not support onload onerror. document. createelement ('object '). data = URL method. disadvantage: FF parses HTML and executes the script resource object in HTML when loading HTML. type = "application/X-Shockwave-flash. disadvantages: 1. The resource is flash ....

 

The solution to loading. js. CSS without parsing and rendering is as follows: <Script  Type = "text/cache"  Src = "url"> </SCRIPT> (Text/here is random. We want to deliberately make the browser not understand.) In this way, the browser can pre-load any resource without parsing and executing the resource. for example,. JS. but Firefox does not support this. if Firefox does not know type. therefore, no HTTP request will be initiated. the Yahoo method is to use the object element for loading. The firefox3.0 + Browser allows you to do this. however, if we need to load a text/html resource. if the object tag is loaded, the browser will parse the HTML and execute the script. this is intolerable. imagine. our current page is running well. suddenly, the music is played due to the pre-loading of a page. or execute the script for a page. we need to use link element (rel = "stylesheet") for Firefox. it ensures that HTML loading is not parsed. however, the link element is in Firefox. no onload, onerror. 1. But we need to load the current resource after Firefox parsing. we need to automatically remove the dynamically added link tag from the Dom. the same is true for script labels. at the beginning, chrome8 + and safari5 + no longer support loading script resources that are not recognized by type. operabrowser does not have much to do with the script tag, just like Firefox's link element. type is unknown. the onload onerror is invalid. to Code More robust. I thought of using the HTML5 web worker importscripts () method. If you are not familiar with this method, you can   Http://www.cnblogs.com/_franky/archive/2010/11/23/1885773.html obviously worker provides us with a relatively perfect sandbox mechanism. (Not perfect. The reason is the last one .) Unfortunately. the worker + script solution still cannot solve the opera9.6-firefox3.0-browser. if you need to solve these two browsers. earlier versions. therefore, we need to use the experience of some negative teaching materials. for earlier versions of opera. you can use round robin to solve the problem. although opera does not know the type of the script tag. onloda onerror is invalid. however. actually. scriptelement. readystate is changed. we can poll for the value of readystate. (As IE does ). to determine whether the resource has been loaded. if you have doubts, you can look at the http://www.cnblogs.com/_franky/archive/2010/06/20/1761370.html of course. what I want to hear most is. our project department needs to consider opera 9.6 ff3.0 and old antiques .. Okay. Two groups of pseudo code are provided at the end. Of course, some basic objects relying on the Code do not exist, leading to execution failure:  

// Negative textbook. // script element + link element (Firefox loads html) + object element (Firefox js css ...) // call the dispose () method at the appropriate time to remove too many nodes. (dragged down by Firefox and opera) void function (Win, Doc, Head, NS) {VaR _ class = '_ preload_cleartempelements _', _ Tag = 'script '; if (NS. preload) {return;} VaR _ preload = NS. singlepreload = !! Doc. getboxobjectfor | win. Unzip innerscreenx! = NULL? (_ Tag = '*') & function (Surl, ishtml) {// ff3.0 + starts to support loading other data types of objects. if it is HTML, the HTML var El will be parsed; If (ishtml) {El = Doc. createelement ('link'); El. type = 'text/CSS '; El. rel = 'stylesheet '; El. href = Surl;} else {El = Doc. createelement ('object'); El. data = Surl;} el. classname = _ class; head. appendchild (EL);}: function (Surl ){//! FF var El = Doc. createelement ('script'); El. type = 'text/C'; El. classname = _ class; El. src = Surl; head. appendchild (EL) ;}; ns. preload = function (aurl) {typeof aurl = 'string' & (aurl = [aurl]); For (VAR I = 0, L = aurl. length; I <L; I ++) _ preload (aurl [I]) ;}; ns. preload. dispose = function () {var list = NS. dom. $ C ('_ preload_cleartempelements _', _ Tag, head); For (VAR I = List. length; I --;) {head. removechild (list [I]);} List = NULL;} (window, document, document. getelementsbytagname ('head') [0], visit. util );

// Worker + script introduces worker. jsonmessage = function (e) {var A = E. data. tostring (). split (','); For (VAR I = 0, L =. length; I ++) {try {// prevents the script from being executed due to loading failure. otherwise, an imirtscripts. apply (null, a); solves the problem. // now, the advantage of parallel loading is also lost. however, there is a solution to this problem. importscripts (A [I]);} catch (e) {}} postmessage ('loaded') ;}; void function (Win, Doc, Head, NS) {VaR _ dom = NS. dom, _ workerurl = 'js/worker. js', // worker. JS path _ emptyfn = func Tion () {}; if (NS. preload) {return;} If (win. worker) {// ff3.5 + opera10 + safari4 + chrome3 + (requires worker. JS Support) ns. preload = function (aurl) {VaR _ w = new win. worker (_ workerurl); _ w. onerror = _ emptyfn; _ w. onmessage = function (e) {e. data = 'visitloaded' & (_ w. terminate (), 1) & (_ w = NULL); //}; _ w. postmessage (aurl) ;};} else if (! Doc. getboxobjectfor |! Win. opera) {// IE6 + safari3-chrome2-ns. preload = function (aurl) {for (VAR I = 0, L = aurl. length; I <L; I ++) {_ Dom. loadjs (aurl [I], null, null, 'text/C') ;};} else {// ff3.0-opera9.6-ns. preload = _ emptyfn ;}( window, document, document. getelementsbytagname ('head') [0], visit. util );

 

Finally, Let's explain why woker's sandbox is not good enough.

 

1. If the resource loaded by the importscripts method is a script, it will actually be executed. Therefore, once the resource owner understands all this, you can execute Postmessage ('loaded ')Statement script.

Apparently homepage: E. Data = 'loaded' & (_ w. Terminate (), 1) & (_ w = NULL );This will be executed. The results will be inaccurate.Although this vulnerability can be bypassed through a random key verification method, the two and three problems are considered.

Only repair. This vulnerability does not make much sense. The importscripts statement must be placed in an independent closure. The additional loss is meaningless. It is worth the candle.

 

2. Execute the endless loop script for the loaded resources. The postmessage ('loaded') of other browsers except FF may not be executed.

 

3. note. the worker of the Opera Browser calls self. problems caused by close... we cannot solve this problem .. very tangled. fortunately, we just cannot determine whether the resources have been loaded...

The loss can be ignored. As long as there is no security problem, it is acceptable.If possible, it would be okay to add a timeout mechanism to compensate for the risks caused by such problems... after all, our ultimate goal is to pre-load resources.

 

 

4. A script introduced by importscripts executes a similar script while (! Window) postmessage ('hellow'); it is a card equivalent to the tragedy homepage process.

Similarly, importscripts () is used for recursive calling.

 

There are also ways to prevent blocking. You can think about it yourself (the blacklist + timeout system is prompted .)

Refer to pseudocode:

_ W. onmessage = function (e ){
Win. cleartimeout (_ timer );
_ W. Terminate ();
_ W = _ w. onmessage = NULL;
E. Data! = Key & _ preload. addblacklist & _ preload. addblacklist (aurl. Shift (), aurl), E. data );
};