Why is the browser showing the raw html over a slow connection (instead of interpreting it)?

I have several posts about how people view raw html in their browser (instead of having their browser interpret it). This seems to be happening on slow connections. When this happens, if the user reloads the page, the page will be interpreted correctly. Are there any html specific things that might cause this (as opposed to server settings)?

+2


source to share


3 answers


Maybe if the connection timeouts before the HTML is fully sent is possible. The DOM will be essentially incomplete and may not be able to interpret correctly. Let's just assume.



+1


source


I assume it is called FOUC .

Unpinned Content Outbreak (FOUC) The instance in which the web page is displayed is briefly painted over before loading the external CSS stylesheet. The page fixes itself as quickly as the style rules are loaded and applied, however the shift is quite noticeable and distracting. After the web page appears, the viewer sees the unsettled HTML converted into a different document.

Why does the page take longer to load?



One of the most challenging tasks when working in a web browser is accurately measuring how long you load web pages. To understand why this is difficult, we need to understand exactly what browsers do when you ask them to load a URL.

So what happens when you go to a url like cnn.com? Well, the first step is to start collecting data from the web. This is usually done on a thread different from the main UI thread.

As data is entered for the page, it is fed to the HTML tokenizer. It's up to the tokenizer to get the data and figure out what the individual tokens are, for example, start tag, attribute name, attribute value, end tag, etc. The denominator then feeds the individual tokens to the HTML parser.

The parser's job is to create a DOM tree for a document. Some DOM elements also represent subresources like stylesheets, scripts and images, and these loads need to start when these DOM nodes are encountered.

In addition to creating the DOM tree, modern CSS2-compliant browsers also create separate render trees that represent what is actually shown on your screen when drawn. It is important to note two things about DOM tree rendering.

(1) If the stylesheets are still loading, it is wasteful to build the render tree as you don't want to draw anything at all until all the stylesheets have been loaded and parsed. Otherwise, you will run into FOUC problem (outbreak problem with non-stationary content), where you will show the content until it is ready.

(2) Images should start loading as soon as possible, which means they should come from the DOM tree, not the render tree. You don't want to wait for the CSS file to load to start loading images.

There are two options for solving the problem of delaying the construction of the render tree due to the loads stylesheet. You can block the parser while the stylesheet is loading, which has the disadvantage of keeping you from parallelizing resources, or you can enable parsing but just hinder the rendering tree. Safari does the latter.

External scripts should block the parser by default (because they can document.write). The exception is defer specified for scripts, in which case the browser knows that it can delay the execution of the script and continue parsing.

What are some of the relevant milestones in the life of page loading since figuring out when you can actually reliably render content?

(1) All stylesheets loaded.
(2) All data for the HTML page has been received.
(3) All data for the HTML page has been analyzed.
(4) All sub-resources loaded (onload handler time).

More on this here .

Hope this helps explain why this is happening.

+1


source


If the HTTP header has been malformed to send HTML with the wrong mime type, it will appear as text and not rendered HTML.

0


source







All Articles