• En
  • /
  • Jp
  • Browser-painting and Web Performance

    2018.12.18
    • Share
    • Twitter
    • Google+
    • はてなブックマーク
    Author

    My name is Sherrylou Francisco, Junior Front end Web Developer at COMMUDE Philippines.
    I’ve been working as a web developer -both front end and back end- for about 2 years.
    I’ve always considered myself as a creative thinker, I love finding alternative solutions to problems and sharing my discoveries to mediocre programmers like myself.

    Introduction

               To render a page, the browser will have to find, download, and parse the CSS files so it is important that we get it onto the user’s device as fast as possible. Any delays can affect the initial render, which means the user will have to stare with a blank display for seconds or so.


    How CSS can be a bottleneck on your network

               Listed below are the instances where your CSS files can become a big bottleneck on the network, how we can mitigate it, therefore shortening the critical path and reducing our time to Start Render.


    Employ Critical CSS

               If you can, one of the most effective ways to shorten the rendering time is to use a critical CSS pattern: identify all styles required for initial rendering, usually the styles needed for everything at the top, put them into the style tags in the document then load the remaining styles off of the critical path.

    CONS: Although this strategy is effective, it is not easy: highly dynamic pages can be difficult to isolate files from.


    Split Your Media Types

               If achieving Critical CSS is proving quite tricky-and it probably is CSS file out into its individual individual CSS file out into individual individual individual Media Queries. The practical upshot of this is that the browser will will download any CSS needed for The critical context (medium, screen size, resolution, orientation, etc.) with a very high priority, blocking the Critical Path, and download any CSS not needed for the current context with a very low priority, completely off of the Critical Path Basically , any CSS not needed to render the current view is effectively lazyloaded by the browser.

    If we are bundling all of our CSS into one file like this:


    <link rel = “stylesheet” href = “all.css” />

    the single CSS file carries a Highest priority.


    If we can split that single, all – render blocking file into its corresponding media queries :


    <link rel = “stylesheet” href = “small.css” media = “(min – width: 20 em)” />

    <link rel = “stylesheet” href = “medium.css” media = “(min – width: 64 em)” />

    <link rel = “stylesheet” href = “large.css” media = “(min – width: 90 em)” />

    <link rel = “stylesheet” href = “print.css” media = “print” />

    Then The Network Will Treat The Files Differently, The CSS Files That Are Not Required To Render The Current Context Will Be Assigned As The Lowest Priority.

    The browser will still download all CSS files, but it will block rendering on files needed to fulfil the current context.

    Avoid @import in CSS Files

               To speed up rendering, we can make another solution that is very easy. Avoid using @import in your CSS files.

    @import, how it works, is slow. In fact, this is bad for the initial render performance. This is because this is making more active round trips on the critical path:
    • Download HTML;
    • HTML requests CSS;
    • CSS requests more CSS;
    • build the Render Tree.
    Place <Link Rel = “Stylesheet” /> In <Body>

               This final strategy is effective and progressive rendering It’s also very component friendly.


    Loading your css codes in a single stylesheet has three serious inefficiencies:

    • Each specific page will use only a small set of styles found in your css file: the browser have definitely downloaded more CSS than the current page actually need.
    • It is bound to an inefficient caching strategy: a change to, say, the background colour of the selected day on a date picker that is only present in one page, would require that we cache-bust the whole css file.

    Each representation of a css file is a block: it does not matter if the current page only needs 17% of the file of the style sheet, we still have to wait until the remaining 83% before the page renders


    CONS: since this solution means you will have to split your css file to multiple smaller css files and link them one by one on the body tag, your html file as well as your directory will look messier which will affect its readability.

    Summary

    To summarize the best network performance practices for loading CSS:

    • Lazy load any CSS not needed for Start Render: this could be Critical CSS or splitting your CSS into Media Queries.
    • Avoid @import:

        – In your HTML;

        – in CSS especially;

        – and beware of oddities with the Preload Scanner.

    References

    https://css-tricks.com/understanding-critical-rendering-path/
    https://css-tricks.com/browser-painting-and-considerations-for-web-performance