The “Critical Path” defines the process of the browser downloading, parsing and rendering a webpage. This is broken up into the following process:
- Network download
- HTML DOM parse
- CSSOM parse
- Layout
- Paint / Render
- JavaScript onload
There are many bottlenecks that can occur during these steps and limiting issues in each one is paramount to delivering a quick and performant webpage.
Network Download
Note: Downloading additional assets can add time to first paint or interactive mode
Make as few network requests as possible. The more requests, the more time and bytes are sent to the browser. If you can combined assets so that they make one single request and do not compromise your asset, do it.
By compressing, minifying and simplifying assets, their file size and network size will be smaller. This is a good practice to start with as more and more users are using mobile connections. By starting smaller, fewer bytes will be sent and then only when you need to scale up the resources, more will be downloaded (i.e. “Lazy Loading” or “opt-in” loading).
By utilizing loading techniques such as prefetch or preload assets, those that are “precached” will be available the next time around and will not have to re-download. This, in turn, will speed up loading time as well as reduce network bandwidth usage.
Sharding
There is a technique of using multiple (sub)domains to serve assets from in parallel. With the advent of HTTP/2, this is no longer required. The reason for this trick was to get around the browser’s limitations of how many assets could be served from a single domain at a time. By using multiple domain locations, the browser could open up as many domains as listed and serve all files concurrently.
DNS Lookup
Each time you make a request, if that asset is not cached, the browser has to make a DNS lookup. The DNS handles the translation of a alphanumeric string into a numeric I.P address. This can be an expensive process if there are multiple requests going to different domains. However newer methods such as DNS preconnect and HTTP/2 can assist the process.
HTML DOM Parse
Note: DOM parsing usually doesn’t add too much time to process, unless document is really large or all DOM nodes are created via JavaScript
Each webpage is comprised of HTML tags that construct the Document Object Model. Once each tag has been parsed, it is up to the browser to begin the process of constructing these tags into nodes for layout.
CSSOM Parse
Note: CSS downloading and parsing will block the painting/rendering path
Any styles that are applied to the document (either through inline, tags or stylesheets) will next be parsed and their instructions applied to the CSSOM (CSS Object Model). This model constructs the graphics that will be eventually painted and rendered on the screen.
It is recommended to send the CSS as early as possible when loading a document. However, ensure that the amount of CSS loaded early in the process is fairly minimal as it will block the rendering process. One technique that can help with this is to have a very small amount of “bare-bones” CSS to get started and then have external supplemental CSS to load later on in the load cycle. This basic CSS would be inlined or embedded in a style tag to render immediately without a network request. The obvious downside with this is that it is not managed in a stylesheet. However, with today’s build techniques having includes or build steps to include inlined styles is fairly common.
Extra Notes
- Cache CSS
- Gzip
- Minify it
Unused CSS
Make sure to remove any unused CSS rules. Each additional rule that is added to the stylesheet or declaration will need to be parsed by the CSSOM. If that rule does not apply to the current page, it will be ignored in the painting but the resources are still being used to parse it.
There are many tools out to analyze a page’s HTML and CSS to verify how many unused rules exist. Also, implementing techniques such as code splitting or tree shaking will take care of the unused rules. There’s also some discussion of using scoped CSS modules to handle the unused rules.
Layout
TODO
Paint
TODO
JavaScript
JavaScript will block any assets from being downloaded. This is due to the browser needing to halt the downloading process to address any script changes that may occur.
A good idea when using third-party scripts is to place them as the last script elements to be downloaded as they may pause the downloading of additional assets. These assets may not be fully downloaded until the third-party script has been executed completely, which could take a while.
Note the previous statement was pulled from an article written in 2013 and newer techniques of async and defer should help ease the issue outlined.