DEV Community: Goutham JM

Advanced Front End Developer Essentials - Part 2

Goutham JM — Sun, 17 Oct 2021 03:31:00 +0000

This post is a continuation of Advanced Front End Developer , Interview Essentials - Part 1 ,if you haven't read it I strongly recommend you to go through the post where I have explained the CRP in detail

Optimizing the Critical Rendering Path is very essential for performance of a site , and always keep in mind the below rule

You cannot optimize something that you cannot measure

1.DOM Optimization

You should stream HTML as fast as you can ,we can achieve that by these step's minification,compression and caching the HTML.

In which stage of CRP, Do you think will the page be rendered ?
It will be rendered when the render tree is constructed ,i.e. just after CSSOM has been constructed, and it will be the render blocking step , so it becomes crucial to optimize CSSOM

2.CSSOM Optimization

As CSS is a render blocking resource,always keep your CSS lean, deliver it as quickly as possible, and we can use media types and queries to unblock rendering

If we have some CSS styles that are only used under certain conditions, for example, when the page is being printed or being projected onto a large monitor,but you are viewing in a mobile ,then we can block rendering on the resources that are not used.

CSS media types and media queries allow us to address these use cases,in the below example if we maintain a separate style sheet for different use cases , Example : we may need to apply certain styling for print or in responsive site we can mention a specific width during which case only the style sheet must be imported

<link href="style.css" rel="stylesheet">
<link href="print.css" rel="stylesheet" media="print">
<link href="other.css" rel="stylesheet" media="(min-width: 40em)">

When declaring your style sheet assets, pay close attention to the media type and queries; they greatly impact critical rendering path performance

Explanation:

<link href="style.css"    rel="stylesheet">
<link href="style.css"    rel="stylesheet" media="all">
<link href="portrait.css" rel="stylesheet" media="orientation:portrait">
<link href="print.css"    rel="stylesheet" media="print">

The first declaration is render blocking and matches in all conditions.
The second declaration is also render blocking: "all" is the default type, so if you don’t specify any type, it’s implicitly set to "all". Hence, the first and second declarations are actually equivalent.
The third declaration has a dynamic media query, which is evaluated when the page is loaded. Depending on the orientation of the device while the page is loading, portrait.css may or may not be render blocking.
The last declaration is only applied when the page is being printed, so it is not render blocking when the page is first loaded in the browser.

Avoid CSS imports

The CSS import (@import) directive enables one stylesheet to import rules from another stylesheet file. However, avoid these directives because they introduce additional roundtrips into the critical path: the imported CSS resources are discovered only after the CSS stylesheet with the @import rule itself is received and parsed.

Put CSS in the document head

Specify all CSS resources as early as possible within the HTML document so that the browser can discover the <link> tags and dispatch the request for the CSS as soon as possible.

3. JS Optimization

JavaScript allows us to modify just about every aspect of the page: content, styling, and its response to user interaction . JavaScript can also block DOM construction and delay when the page is rendered. To deliver optimal performance, make your JavaScript async and eliminate any unnecessary JavaScript from the critical rendering path

By default, JavaScript execution is "parser blocking": when the browser encounters a script in the document it must pause DOM construction, hand over control to the JavaScript runtime, and let the script execute before proceeding with DOM construction.

Problem:

Let's take the below example where there is a style sheet as well as script that modify the <p> tag , so will the text be rendered black or red , the answer to this lies in the order of the execution

Page requests for HTML, and it will start building the DOM
Then it will encounter style and request for CSS resources ,during this time CSS doesn't know whether the script will modify the CSS, so it will wait for CSSOM to be constructed
After CSSOM is constructed, then JS will be executed and will build the Render Tree

CSS blocks script as well as rendering page, so it becomes crucial to optimize the CSS

Solution :

1.All JS code might not modify the DOM in such cases one way we can optimize JS it to load it after DOM has been loaded ,like below

   <script>
      function loadFunction() {
        alert("Window is loaded");
      }
      window.onload = loadFunction();
    </script>

2.Another way to solve this is to add async attribute to the script tag , it does two things - it doesn't block DOM construction, and CSSOM construction , so basically what it does is it will allow JS not to block CRP
3.There is also a defer attribute that you can add to the script tag that tells the parser that the script should wait to execute until after the document is loaded

Summary:

So let's see what all the options we have to optimize the CRP

Minification,Compression and Caching - HTML,CSS and JS
Reduce critical resources - CSS media query ,avoid imports and use critical inline CSS , JS - with async or defer attribute
Shorten CRP length , i.e. reduce the number of round trips for fetching resources , there are a ton of ways to optimize it based on different communication protocol,You can refer it here
Optimize the order in which the remaining critical resources are loaded: download all critical assets as early as possible to shorten the critical path length.

There are other methods of optimizing a site ,in my next post I will discuss on how to achieve Fast Load time for your site

References:

Advanced Front End Developer Essential - Part 1

Goutham JM — Fri, 15 Oct 2021 03:45:37 +0000

Critical Path Rendering

It is the sequence of steps a browser undergoes to convert HTML,CSS and JS into pixels

Why do you need to understand it ?

By optimizing the critical rendering path, we can significantly improve the time to first render of our pages. Further, understanding the critical rendering path also serves as a foundation for building well-performing interactive applications.

Optimizing for performance is all about understanding what happens in these intermediate steps between receiving the HTML, CSS, and JavaScript bytes and the required processing to turn them into rendered pixels - that's the critical rendering path.

The Critical Rendering Path undergoes 5 different steps ,as mentioned in the below image.

Let's try to understand each step one at a time

1.HTML to DOM

When browser receives HTML , It needs to convert the HTML into Document Object Model ,It undergoes 4 small steps to construct the DOM Tree - Conversion , Tokenizing , Lexing and DOM construction

Conversion: The browser reads the raw bytes of HTML off the disk or network, and translates them to individual characters based on encoding (Ex : UTF-8).
Tokenizing: The browser converts strings of characters into distinct tokens— for example, "", ""—and other strings within angle brackets. Each token has a special meaning and its own set of rules.
Lexing: The emitted tokens are converted into "objects," which define their properties and rules.
DOM construction: The created objects are linked in a tree data structure that also captures the parent-child relationships.

Note : DOM Tree can be partially rendered and is considered to be render non-blocking

2.CSSOM

CSSOM undergo similar steps as HTML to DOM

The CSS bytes are converted into characters, then tokens, then nodes, and finally they are linked into a tree structure known as the "CSS Object Model" (CSSOM)

Any text contained within the tag, that is placed within the body element, has a font size of 16 pixels and has red text—the font-size directive cascades down from the body to the span. However, if a span tag is the child of a paragraph (p) tag, then its contents are not displayed.

Note : CSSOM cannot be partially rendered and is considered to be render blocking , we cannot render a partial CSSOM due to the reason that CSS might have different selectors with varied specificity due to which there will a good chance of rendering wrong style

3. Rendering Tree

The CSSOM and DOM trees are combined into a render tree, which is then used to compute the layout of each visible element and serves as an input to the paint process that renders the pixels to screen. Optimizing each of these steps is critical to achieving optimal rendering performance.

Starting at the root of the DOM tree, traverse each visible node.
- Some nodes are not visible (for example, script tags, meta tags, and so on), and are omitted since they are not reflected in the rendered output.
- Some nodes are hidden via CSS and are also omitted from the render tree; for example, the span node---in the example above---is missing from the render tree because we have an explicit rule that sets the "display: none" property on it.
For each visible node, find the appropriate matching CSSOM rules and apply them.
Emit visible nodes with content and their computed styles.

Note: As a brief aside, note that visibility: hidden is different from display: none. The former makes the element invisible, but the element still occupies space in the layout (that is, it's rendered as an empty box), whereas the latter (display: none) removes the element entirely from the render tree such that the element is invisible and is not part of the layout.

4. Layout

Up to this point we've calculated which nodes should be visible and their computed styles, but we have not calculated their exact position and size within the viewport of the device---that's the "layout" stage, also known as "reflow."

Explanation:
The width 100% of body is calculated based on the view port width , if in the meta tag we mention like below , the width will be screen size of device ex: Mobile will be 320px , so width:100% will be of body 320px , div as it is 50% of parent will be 160px and p is 50% of 160px i.e. 80px

<meta name='viewport' content='width=device-width'>

If viewport is not mentioned for device width , then it will be 980px by default

5. Painting or Rasterizing

This is the final stage, which converts each node in the render tree to actual pixels on the screen

The time required to perform render tree construction, layout and paint varies based on the size of the document, the applied styles, and the device it is running on: the larger the document, the more work the browser has; the more complicated the styles, the more time taken for painting also (for example, a solid colour is "cheap" to paint, while a drop shadow is "expensive" to compute and render).

Summary:

A quick recap of the browser's steps:

Process HTML markup and build the DOM tree.
Request CSS and JS resource (Not explained in this post)
Process CSS markup and build the CSSOM tree.
Execute JS (Not explained in this post)
Combine the DOM and CSSOM into a render tree.
Run layout on the render tree to compute geometry of each node.
Paint the individual nodes to the screen.

I have left step 2 and 4 related to JS on purpose , I will explain those steps in my upcoming posts and I will update the link to those posts here , The second part of the post can be viewed Advanced Front End Developer , Interview Essentials - Part 2
, Happy to receive any constructive feedback

References:

React 17 : Why it's so important ?

Goutham JM — Wed, 09 Sep 2020 21:30:45 +0000

React 17 is out and it has been 2.5 years since the release of React 16, React 16.x included many new changes like Hooks,Context etc.,But the new React 17 has no new features but it's a right move they have done this time before going to that let's see some minor changes which has happened

Changes to Event Delegation : React will no longer attach event handlers at the document level. Instead, it will attach them to the root DOM container into which your React tree is rendered

Why this is important ?

It will make it easier to use React with other JS frameworks.
It is safer to use a React tree managed by one version inside a tree managed by a different React version.

No React import : If you were using Create React App boiler plate(cra) or npm to download react and you would be importing React in every jsx or js code ,now it is no longer required

import React from "react";

onScroll Bubbling Event : In React previous version there was a lesser known bug , the parent element used to capture the scroll event of the children this was causing an issue in using the scroll event listener, this has been fixed now
No Event Pooling : For those who don't know what Event Pooling is: The event handlers that we have in any react-app are actually passed instances of SyntheticEvent(A Wrapper for native browser events so that they have consistent properties across different browsers).

Whenever an event is triggered, it takes an instance from the pool and populates its properties and reuses it. When the event handler has finished running, all properties will be nullified and the synthetic event instance is released back into the pool.

This was build to actually increase the performance but It didn't improve the performance in the modern browsers and also it used to confuse the developers so they decided to remove it.
Effect Cleanup Timing :The useEffect hook in React 16 runs asynchronously but the cleanup which we used , like this used to run synchronously this introduced an issue , Example: If you called an Api or An Animation and before the action is complete if the component gets unmounted

Now it is no longer an issue as it runs asynchronously even if the component is unmounted , the cleanup will happen , resulting in better performance

useEffect(() => {
    event.subscribe()
    return function cleanup() {
        event.unsubscribe()
    }
})

You might be confused are these not features ?,these are more of changes internally and bug fixes good to know ,but this release is a right move, now is the right time to migrate your old react projects from class to functions based on hooks or implement context , this will give enough time for both business and developers to catch up to the fast pace in which react was moving.
If you find any new feature , please put it in the comments

I am a Full Stack JS Developer,This is my first article in Dev, any suggestions or constructive feedback on the article are welcome