In my previous article, I mentioned a method of using IFRAME to load non-blocking scripts. Because I have a lot of prejudice against IFRAME, I did not discuss this issue in my previous article.
After the article was published, a netizen asked me this question. below is the original text of his question. First, let's see what he sent me, as shown below:
In my e-commerce background system, the table control is flexigrid, which contains an IFRAME. Each tab is an IFRAME. The problem is, if one or more IFRAME files are loading data, they are not fully loaded yet. If at this time, I open another tab to search for data, which may involve a large amount of data, or submit the data (Other IFRAME may still load the data). At this time, it is easy to see that the browser is stuck and has been circling. This is also related to the JS blocking you mentioned. What is the relationship between thread blocking and the single-thread feature of JS ~~
This phenomenon is very interesting, just as I mentioned in my previous article that I think about the sources of non-blocking Script Loading, studying the phenomenon provided by this friend should also give us a lot of GAINS.
First, this friend mentioned, "If one or more IFRAME files are loading data, they will not be loaded. If at this time, I will open another tab to search for data, A large amount of data may be involved, or data may be submitted (Other IFRAME may still be loading data). At this time, it is very easy to see that the browser is stuck and is always in a circle. "This phenomenon gives me a question:
First, we need to make it clear that when using IFRAME for a page, it is equal to embedding a page in a page. The SRC page pointed to by IFRAME is actually relatively independent from the parent page, so a page with IFRAME is, the relationship between the loading process of the parent page and the loading process of IFRAME is as follows: does the parent page need to wait until all the resources on the IFRAME page are loaded before the onload event is triggered, the onload event of the page is triggered, which indicates that the busy indicator of the page is over, and the busy indicator is an important indicator to measure whether the page is blocked.
Fortunately, someone has already helped us with this experiment. Here I will describe the method of this experiment:
The blocking loading method is directly written on the page:
<iframe src=”url”></iframe>
IFRAME URLs point to four types of pages:
1. the URL points to an empty document. The blank document does not mean that the webpage to which the page points does not exist. Instead, it points to only the most basic HTML in the webpage, for example:
At this time, IFRAME loading will not be blocked due to internal static resources.
2. The page pointed to by the URL contains images;
3. The page pointed to by the URL contains external scripts;
4. The page pointed to by the URL contains an external CSS style file.
The above static resources, experiment designers all delayed their loading, and the results of the experiment are disappointing. These static resources load will block the loading of the parent page, that is, the loading of IFRAME prolongs the busy time to indicate the end time.
Next, the experimenter made another experiment. At this time, the SRC of IFRAME in the parent page is set to null, and then the JavaScript code is used to set the SRC value for IFRAME, the Assignment time is also before the onload event, and the URL points to the same as the previous experiment. The result is that in Safari and chrome with WebKit as the kernel, page loading becomes faster, the loading of IFRAME does not block the loading of the parent page, but this result is disappointing in other browsers. Blocking may exist, or even worse than before.
The loading of IFRAME can block the loading of the parent page. In the preceding description, if an IFRAME is not loaded, you may choose another IFRAME and the other IFRAME is loading the new page, this description shows that the iframe src of this friend should be set in Javascript, rather than in advance. His scenario conforms to the situation in Experiment 2. Another problem occurs here. The first IFRAME may be synchronized with the homepage Resource load, that is, the homepage may not trigger the onload event, why can users still trigger the loading operation of IFRAME? According to my original logic, the page should be unable to receive any response at this time. Here I want to correct this idea, page blocking does not mean that the page stops receiving operations performed by the user. For example, in IE browser, if the page is blocked, the user clicks the button twice, the browser will regard the user's operations as effective and add the user's operations to the UI thread executed by the browser. This is a compromise of the browser for poor performance web pages.
IFRAME blocks page loading for further reasons. First, the slowest loading in the DOM element of the IFRAME page. You can see the figure below:
We use Dom to create IFRAME, A, Div, srcipt, and style nodes on the page. The first column is to create 10 nodes, and the second column is to create 100 nodes, the third column is the creation of 1000 nodes. The value indicates the creation time. The more IFRAME is created, the longer the time is, And the IFRAME itself is the bottleneck of page performance.
In the previous article, I mentioned that to improve the parallel download of page resources, a website can place common static resources under an independent domain name. Cross-origin can increase the number of page connections, the IFRAME page has two URLs. Can IFRAME be used to add parallel downloads? If the URL of the IFRAME is different from the URL of the parent page, can I add a question that I have not tested and cannot answer, the iframe url used by him will certainly be in the same domain as the parent page, because his IFRAME is used for Layout rather than embedding other web pages, the result of the same domain of IFRAME and the parent page is that the number of concurrent connections cannot be increased, because IFRAME points to a complete page. In addition, the IFRAME mentioned above will actually block page loading, therefore, in this scenario, when the browser loads two independent pages at the same time, it must follow the method of loading one page. The result is that the page will naturally become slower.
Because this friend's application is an internal console, its website will never do any optimization work to improve the website performance. One of the following is: cache external CSS files and JS files, so this problem will certainly occur on this friend's website. The first IFRAME has not been fully loaded, and the user opens the second IFRAME, the external CSS files and JS files used by these two IFRAME may be mostly the same, but they will be reloaded in each IFRAME, and the first IFRAME has not been fully loaded, it also blocks the loading of the second IFRAME to static resources. The more IFRAME is enabled, the more serious the blocking will be. The consequence is that the website is getting slower and slower.
So how can we help this friend solve his problem? The best way is to remove IFRAME and use Div to implement tabs. This is too cruel. To refactor the entire front-end code, this friend asked me not to do this.
Therefore, we need to consider the less costly method. The following is what I think of at night. I hope the experts who have read my blog will have more and better suggestions. What I think of is as follows:
- The performance problem of this website is due to the excessive use of IFRAME, so we should reduce the IFRAME, so this friend can change the layout of the page homepage to the traditional layout, that is, place the menu to the left of the page, remove the tab from the page, and there is only one IFRAME In the workspace, so you only need to modify the home page. However, this will reduce the user-friendly feature. The advantage of using the tab is that IFRAME can have a memory function, but the page must be re-opened if an IFRAME is clicked on the left menu, however, the loss of this function is more important than the loss of performance.
- Add the cache function to the static resources on the page, and cache external JS files, CSS files, and images. I don't know the language used by this friend's server. If it is Java, the Web containers produced should be Tomcat and JBoss. I still don't know how to set static resource cache for these Java Web containers. It is best to put static resources in Apache, in a web server such as ngnix, if a static resource server is used, it is better to provide an access address different from the domain name of the master server, which can also increase the number of concurrent browser downloads.
After writing this article, I would like to reiterate my hope that Daniel can read my article and tell us more and better ways.
By analyzing the relationship between IFRAME and non-blocking scripts, we can better understand IFRAME.