Directory of RSS feeds

RSS feeds in the directory: 374

Added today: 0

Added yesterday: 0

Hi-Tech / Internet

CSS and network performance

Css-live - Severstal your world! 05.02.2019 at 10:39

Community that speaks the languages of HTML, CSS and JavaScript

Translation of the article CSS and Network Performance from the site published on with permission of the author — Harry Roberts .

Despite the fact that the site has more than ten years is called "CSS magic" for the last time, it was not a single article related to CSS. Let me straighten it, combining two of my favorite topics: CSS and performance.

the critical CSS for the page display browser will not start rendering until you find, download and esparcet all the CSS — it is therefore extremely important as soon as possible to obtain it on the user's device. Any delay on the critical path will affect our initial rendering, forcing the user to see a blank screen.

what is the main problem?

that's why CSS is so important for performance:

Browser can't display the page until the build tree rendering; tree rendering is obtained from the DOM and CSSOM together; DOM is the HTML plus the blocking any JavaScript that affects it; CSSOM — all CSS rules applied to the DOM with the attributes async and defer can easily be made non-blocking JavaScript to make asynchronous CSS is much more complicated; therefore, it is important to remember that page load speed is determined by slowest stylesheet.

Given this, we need as quickly as possible to build DOM and CSSOM. DOM for the most part is constructed relatively quickly, the first server response to a browser request an HTML page is the DOM. However, since CSS is almost always a separate resource from the HTML, build CSSOM usually takes much more time.

In this article I want to consider how CSS can be a bottleneck (as itself and other resources) in the network, and how to mitigate it, thereby reducing the critical path and reducing the time to first render.

Use the minimum required CSS

If possible, one of the most effective ways to reduce the time to first render is to use the pattern "of the minimum required CSS": to define all the styles needed for the initial rendering (usually only styles for that falls on the first screen) to insert them directly into the tags

... will give this a waterfall chart:

the Loss of parallelization in Firefox because of the faulty scanner pre-load (note: the same waterfall diagram is obtained in IE/Edge).

it is clearly seen that the style sheet of @import does not start to boot until the completion of the JavaScript file.

This problem is not something unique to JavaScript. With this HTML all as:

the Loss of parallelization in Firefox due to inefficient scanner pre-load (note: the same waterfall diagram is obtained in IE/Edge).

a Quick solution to this problem is to swap units

all browsers have a remarkable behavior that is intentional and expected, but I don't recall a single developer who is familiar with it. This is doubly surprising, given how much it can affect performance.

the Browser will not execute

in such an arrangement, it is obvious that JavaScript file does not start to be loaded until the CSSOM is created. Any parallelism is completely lost.

because stylesheets before the asynchronous snippet is lost the possibility of parallelization.

it is Interesting that the scanner pre-load would have to pick up the link to analytics.j in advance, but we inadvertently hid it "analytics.js" — string and not getting the src attribute, which can be dismantled into tokens until an element appears in the DOM. That's what I meant earlier by saying "More on that later".

third-Party services often provide these asynchronous snippets for safer loading of their scripts. Also, the developers often leery of such third-party resources, placing their asynchronous snippets later on the page. Let the intentions here are good — "I don't want to place third-party tags are not dependent on CSS, place them above your style sheet.

that's what happens when you follow this pattern:

If you swap the stylesheet and the async snippet, the parallelization is restored.

Now, you can see that we have fully restored the parallelism and the page loads almost twice as fast.

Place any JavaScript without resorting to CSS CSSOM before; place any JavaScript that appeal to after CSS CSSOM

Damn. This article is thorough than I expected.

If we go further, beyond just asynchronous loading of snippets, then how to load CSS and JavaScript as a whole? To solve this, I asked myself the following question, and began to push away from him.

synchronous JS specified after the CSS is blocked until the CSSOM is built; a synchronous JS blocks building the DOM...

then, provided that they are independent from each other — which is faster/preferable?

the Script after styles; the styles after the script?

here is the answer:

If the file has no dependencies, you'd better place your scripts above the locking block styles — it makes no sense to delay the execution of JavaScript for CSS from which this JavaScript is not affected.

(Scanner pre-load ensures that, although the construction of the DOM blocks scripts, CSS is still loaded in a parallel thread.)

If some of your JavaScript depends on CSS and some not, then the optimal order to load a synchronous JavaScript and CSS to split the JavaScript into two parts and upload them on different sides of your CSS:

With this pattern download we and download, and execution occur in an optimal order. I apologize for the tiny details in the screenshot below, but I hope you noticed the little pink tag that represents the execution of the JavaScript. Equations (1) — HTML, which is scheduled to run some JavaScript at boot and/or execute other files; write (2) is performed at load time; recording (3) — CSS, so it does not perform JavaScript; write (4) is not executed until the CSS is complete.

How CSS can affect at what point will run JavaScript.

note: it is important to test this pattern in your specific case: results may vary depending on, whether strongly differ in weight and resource consumption of the JavaScript that is loaded before the CSS, and CSS. Test, test and test.

Place in the

This last strategy is fairly new, is a huge plus for the progressive rendering and the feeling of speed to the user. And it is also very convenient for components.

IN HTTP/1.1 all our styles is usually collected in one large master file. Let's call it app.css:





there are three main disadvantages:

Any individual page uses only a small portion of the styles from the app.css: we are almost certainly downloaded more CSS than necessary. We imposed an inefficient strategy of caching: when you change, say, the background color of the current day is selected in the drop-down calendar, which is on only one page would need to refresh the cache for the entire app.css. The whole app.css block display: even if the current page is required only 17% of app.css, we still need to wait for the download other 83% before we start anything to render.

WITH HTTP/2 you can start to solve items 1 and 2





Now the redundancy can be overcome, because the page can only load CSS, but not everything. This reduces the file size of that block of CSS code at boot.

We can also take a more sophisticated caching strategy, updating the cache only for the required files and not touch the rest.

That we have not solved is the fact that all this still blocks the view of the download rate, we are still limited to the slowest stylesheet. This means that, if for any reason the file download page-footer.css will be long, the browser can't start rendering .page-header.

However, due to recent changes in Chrome (version 69, I think) and behaviour that is already in Firefox and IE/Edge,