DEV Community: Bipul Sharma

Web Performance Optimization- II

Bipul Sharma — Tue, 03 Aug 2021 18:18:13 +0000

About

𝐈𝐦𝐚𝐠𝐞 𝐎𝐩𝐭𝐢𝐦𝐢𝐳𝐚𝐭𝐢𝐨𝐧𝐬: with different file formats, Responsive Images Markup, mannual and automatic optimzations, lazy loading
𝐉𝐒 𝐎𝐩𝐭𝐢𝐦𝐢𝐳𝐚𝐢𝐭𝐢𝐨𝐧: modularization, async-defer, lazy loading, minifiers
𝐂𝐒𝐒 𝐎𝐩𝐭𝐢𝐦𝐢𝐳𝐚𝐭𝐢𝐨𝐧: modularization, critical CSS, using onload and disabled attributes.

Glossary

Shallow depth of feild- very small zones of focus.
Lossy and Lossless images- lossy has loss in quality and file size on compression while lossless has no loss in quality and results in bigger file size on compression.
transparency/opacity- images that is clear and can take the effect of any images behind it
Render blocking- JS stopping the DOM rendering.

Image Optimization

Images are the leading cause of the slow web. We have two conflicting needs here: we want to post high quality images online, but also want our websites and apps to be performant, and images are the main reason they are not. So how do we solve this conundrum? The answer is with a multi-pronged approach, ranging from compression to careful selection of image formats, to how we mark up and load images in our applications.

Image performance is all about how much data is contained within an image and how easy it is to compress that data. The more complex the image, the larger the data set necessary to display it and the more difficult it is to compress. Shallow depth of field means better performance. For photography including products, headshots, documentary, and others, a shallower depth of field is preferred.

If you want to squeeze as much performance as possible out of your images, reducing the size of each image by 87% percent, and then upscaling it by 115%, will actually impact the performance of the image as well. It turns out downscaling a photo by 87% percent, Photoshop will take away pixels and simplify the image to scale it down and reduce the complexity of the image and by upscaling it by 115% percent it preserves image quality well enough that humans can't tell the difference. So we get a image of same size but has significantly less complexity.

The image format or file type you choose for your images will have a direct impact on performance. On the web we generally use one of five formats JPEG, PNG, GIF, SVG, and webP.

JPG/JPEG

Meant for Photos
Lossy image with adjustable compression
High compression means large artifacts(distortion)
Use for Photos when WebP is not an Option

PNG

Meant for Graphics
Lossless image format
Optional transparent alpha layer
Use for computer generated graphics and transparency

GIF

Meant for simple lofi gaphics
Lossy image format
256 colors
Can be animated (but dont use them)
SVG/Video is always a better option

SVG

Meant for advance scalable graphics
Written in Markup, can be included in HTML, CSS
Very small when optimized
Use for vector-based computer generated graphics and icons

webP

Meant for web-based photos
Upto 34% smaller than JPGs
Not supported in older browsers(fallback required)
Used for photos and complex detail images (with fallback)

How to choose what to use?

For photos, use webP (with JPG fallback)
For too complex computer graphics use PNG or JPG (whichever is smaller)
For graphics with transparency use PNG or webP
For scalable computer graphics, icons and graphs use SVGs
Aviod animated GIFs at all cost, use videos instead

Mannual Optimizations

Decide on the maximum visible size the image will have in the layout. No image should ever be displayed wider than a full HD monitor, 1920 pixels. Make sure you also restrict the display width of that image to 1920 pixels, and then center align it. Once you've settled on a width for an image, scale your image to fit that size.
Experiment with compression in webP, JPG
Simplify SVGs by removing unnecessary points and lines
Compare file sizes for JPG, webP and PNG for computer graphics

Automated Optimization

Imagemin is a good choice. You can use it to build a custom optimization function in Node.js. Or add automated image optimization into your preferred build process. Imagemin CLI provides lossless compression for JPEG, PNGs, and GIFs.
You can add dedicated lossy compression for each of them using plug-ins: Imagemin-mozjpeg for JPEGs. Imagemin-pngquant for PNGs and Imagemin-webp for webPs.
Squoosh uses various compression algorithms to optimize images. And it has an experimental CLI you can use to automate that process.
Sharp is also available for use.

Even a fully optimized image can slow down the performance of your site if it's delivered to the wrong browser at the wrong time. This is the problem Responsive Images Markup is meant to solve.

We have responsive images attributes: srcset and sizes.
Source sets allows you to provide a list of image sources for the browser to choose from and sizes defines a set of media conditions (e.g. screen widths) and indicates what image size would be best to choose, when certain media conditions are true. W indicates total pixel width of each of these images.
For example:

If the viewport of the browser is 800 pixels wide. The browser will pick the 1200 pixel wide image because it is the closest size upwards. If you then choose to scale up the viewport by just scaling up the browser window. The browser will automatically pull down larger versions of the image to fill in the space if it's necessary. But the important thing now is, by carefully planning your image sizes you can now deliver appropriately sized image files to all browsers and all devices.

But, for most of your images, the actual displayed width of the image is determined using CSS and media queries. And you rarely display all your images as full width in the browser. To address this, we have the sizes attribute. Sizes holds a list of media queries and corresponding width to save.

For this image, if the viewport is 1200 pixels or wider, the actual width this image will be displayed at will always be 1200 pixels. The reason why I'm still providing the 1920 pixel image here is to provide a higher resolution image to higher resolution displays. The 100 VW at the end of the size of the attribute says, for all other conditions, meaning screen widths under 1200 pixels, the image is always full width because this is a responsive layout.

This is especially important when you have a design where an image has a max size smaller than the viewport width. Which is almost every single image on the web.

Lazy Loading Images
Loading images, videos, and iframes the user never scrolls to has always been a major performance issue on the web. We're simply wasting data that we shouldn't be wasting. To deal with this issue, developers started adding lazy loading JavaScript libraries that would wait for the user to scroll close to an element before the image was loaded by the browser so that instead of loading all the images on a page, only the images the user would actually get to see inside the viewport were loaded by the browser.

Native lazy loading is activated using the loading attribute on the element in question. Lazy, meaning the asset is loaded only when it's close to the viewport, and eager, meaning the asset is loaded immediately, even if it's nowhere near the viewport. There's also a fallback here called auto, but it's not yet in the specification. Now, this loading attribute is also non-destructive, meaning older browsers who do not understand this attribute will simply ignore it and load all the assets as it would normally do. If you want lazy loading support in older browsers as well, you can use a JavaScript solution like lazysizes, which has an extension plugin called native loading, which serves up the JavaScript solution only to browsers that do not support the loading attribute and the new built in lazy loading feature.

JavaScript Optimization

The code we write is optimized for humans, but if we want the code to be as fast as possible and to be performant, it needs to be rewritten for size and effectiveness, and that makes it unreadable for us humans. We now have tools to do this job for us in the form of code minimizers, packagers, bundlers, and more. At minimum, you'll need a development track where the human readable code is stored and a production track where the highly optimized and compressed machine-readable code is stored.

How and when we compress, bundle, load, modularize, and execute JavaScript is becoming more and more important to improving performance. The same can be said for CSS. Modular and inline CSS, progressive loading, and other performance techniques are now essential to ensure the style of a site or application doesn't slow down its delivery.

The modern web platform supports JavaScript modules, separate JavaScript files that export and import objects functions, and other primitives from each other so bundling all JavaScript into one big file, makes no sense on the modern web.
So from a performance perspective heres what should happpen. On initial, load any critical JavaScript necessary to get the app framework up and running and displaying something above the fold should be loaded. Once that's done and the user has something to look at, any necessary JavaScript modules for functionality should be loaded. And from here on out, the browsers should progressively load JavaScript modules only when they become relevant.
JavaScript functionality should be modularized as much as possible and split into dedicated files.

Several immediate benefits to this approach are:

React, uses components. JavaScript modules are the exact same thing. Except they run on the web platform itself and you don't need a bundler to make them work.
Modularization makes ongoing development easier because it provides clear separation of concerns.
Modularizing, JavaScript and loading modules only when they are needed, brings significant performance benefits on initial load.
Modularization means updating some feature in a JavaScript app does not require the browser to download the entire app bundle again. It just needs to download the updated module file with its features, which is way smaller.

When and how the browser loads each JavaScript file it encounters has a significant impact on both performance and functionality.

If we add JavaScript to the head of an HTML document, it will always load and execute as soon as the browser encounters it, which is always before the body is rendered out. This will always cause render blocking.

To prevent this blocking JavaScript has been added to the very bottom of the body element, but this too causes render blocking because as soon as the browser encounters a reference to JavaScript, it'll stop doing anything, download the entire script, then execute the script, and then go back to rendering. So basically, entire page will be loaded before the JavaScript is even loaded which just adds to the performance problems.

We have the async and defer keywords which instruct the browser to either load JavaScript files asynchronously while DOM rendering takes place, and then execute them as soon as they're available, or to load the files asynchronously and defer execution until the DOM rendering is done.

When we add the async tag, the browser will load the JavaScript asynchronously meaning it loads alongside the HTML parsing process. When the script is fully loaded the browser stops the rendering of the HTML until the script is executed and then it continues. Already we're seeing a significant performance enhancement because the parsing isn't paused while the script is being downloaded.

In JavaScript and other programming languages, a synchronous event means one event happens after another, in a chain. Asynchronous means the events happen independently of one another and one event doesn't have to wait for another to complete before it takes place.

In the case of async JavaScript loading the loading is asynchronous, while the execution is synchronous.

Use async anytime you're loading JavaScript and you don't need to wait for the whole DOM to be created first.

Defer is slightly different. We're still loading the script asynchronously when the browser encounters it without render blocking. And then we literally defer the execution of the JavaScript until the HTML parsing is complete.

This is effectively the same as placing the script tag at the end of the body element, except the script is loaded asynchronously, and is therefore much better for performance because we don't render out the entire HTML and then go download the JavaScript. The JavaScript is already downloaded.

Use defer if you need to wait for the whole DOM to be loaded before executing the JavaScript or if the JavaScript can wait.

So here is your performance focused JavaScript loading best practices.

Call JavaScript by placing the script tag in the head
Anytime you load JavaScript in the head, always put async on there unless you have a reason to use defer.
Defer any scripts that need the DOM to be fully built or scripts that you can defer because they don't need to execute right away.
If and only if, you need to support older browsers and you can't allow the browser to wait for things, load your script in the footer the old way and take the performance hit.

Lazy load JavaScript modules and their associated assets only when they're interacted with and needed using import statements.

For example:
import("/path/to/import-module.js")
.then((module) => {
// do something with the module
});
With this you'll not be chaining the events and getting everything to work conditionally on the user's behavior. So you're saving the user a ton of data and only pushing content to the browser when it's needed.
This whole concept can be used with any JavaScript module including external ESM module.
To rewrite everything and turn it into highly optimized human unreadable code we can use minifiers and uglifiers. All major bundlers, including webpack, rollup, parcel, etc ship with minifiers built in. The two most popular minifiers are uglify-js and terser.

CSS Optimization

The number one measure of perceived performance is how fast something loads in the view port of the browser. For a page to render, all the CSS has to be fully loaded because CSS is a cascade and the rule sets at the bottom of a style sheet may well impact the rules that's higher up. If we serve the browser with a huge style sheet with all the styles for the page, it takes a long time to load that style sheet on this content and the performance suffers. To get around this problem, developers have come up with a clever hack called critical CSS.

First, inline any styles impacting the content above the fold(in the viewport) in the HTML document itself as a style tag in the head. Then lazy load and defer the rest of the CSS, using a clever JavaScript trick, so it only loads when the page is fully loaded.
Critical helps us automate this process so that so you don't have to manually copy and paste code every time you update something.

Critical reads the HTML and CSS figures out what rule sets should be inlined automatically inlines that CSS into the HTML document, separates out the non-critical CSS into a step separate style sheet and then lazy loads on the first and non-critical CSS.
Because this tool is built into the tool chain, it can be set up to take place at every build, so you don't have to keep tabs on what styles are critical. This tool also has a ton of options, so you can fully customize exactly what happens within the critical CSS, index file or the HTML file, the CSS, the view port you're targeting, all this stuff can be configured.
For example:

Critical actually spin up a browser and then display the contents in the browser in a defined view port size that we've defined. And then look at what CSS is affecting the content inside that view port and split that out into this critical CSS file. The view port in the example is 320 width, 480 height.

The critical inline CSS that will run before the dom's even built. So this will then define the content that's above the fold.
Then below we have our link elements, but the link element now points at uncritical CSS. And you'll notice the media property is set to print. This is the JavaScript trick.
So what happens now is a regular browser will identify itself as screen. For that reason, this style sheet will not be loaded because it's set to only load for print. Meaning when you're actually printing something. Then, on load, which is an event that is triggered when the page is fully loaded, would change this media to all instead. And at that point, once everything else is done, this extra style sheet will be loaded.

To see how much of your JavaScript and CSS and other code is loaded unnecessarily into the browser, you can use the coverage view in the browser dev tools.

If you see anything marked in red, here, it's a rule that is not currently being used on the page. This is what Critical does, it runs this type of process and then identifies which rules are being used and which rules are not being used, but in the view port, and then it picks and chooses.
If you have one giant style sheet, you need to compare all of these pages and do a bunch of work.
A better solution would be if we could modularize our CSS and split the CSS into smaller components and then load them only if they are needed. And one way we can do that is by deferring loading of CSS until something happens. Now, you already saw an example of that in Critical. You'll remember when we used Critical, the Critical CSS was in lined and then the rest of the styles were put in this uncritical CSS file and deferred.

So, here's a different way of doing the same thing.

Here we set the rel preload and as style attributes into the link element, to tell the browser to preload this style sheet when there's processing available, meaning the loading is delayed to avoid render blocking. Then the on load attribute fires when the CSS is fully loaded and sets the rel attributes to stylesheet so the browser recognizes it and renders it. But this non script element at the bottom is a fall back for browsers that don't have JavaScript, and in that case, they will just immediately load the style sheet.

We could also:

This style sheet will not be loaded by the browser at all until the disabled attribute is removed or set defaults. You can then set up a JavaScript function to change the disabled attribute if, and only if, some event occurs like activating a gallery or triggering a JavaScript or triggering some external function and only then will the browser go to the internet pull down the style sheet, and mount it in the browser.

Lastly,

Loading style sheets in body means you can have each component load its own style sheets on the fly. That way the component brings its own styles to the table and you don't have to load any styles you don't need. This makes for much cleaner and more manageable code and it falls in line with modern component-based development practices.

Web Performance Optimization- I

Bipul Sharma — Mon, 02 Aug 2021 13:43:23 +0000

About
Critical Rendering Path (CRP) and its Optimization, the PRPL pattern and Performance Budget.

Introduction

Web performance is all about making web sites fast, including making slow processes seem fast. Good or bad website performance correlates powerfully to user experience, as well as the overall effectiveness of most sites. Websites and applications need to be fast and efficient for all users no matter what conditions the users are under. To make that happen we use performance optimizations. The MDN web docs breaks down performance optimization into four major areas.

Reducing overall load time
- Compressing and minifying all files.
- Reducing the number of file and other HTTP requests sent back and forth between the server and the user agent.
- Employing advanced loading and caching techniques and conditionally serving the user with only what they need when they actually need it.
Making the site usable as soon as possible
- This is done by loading critical components first to give the user initial content and functionality and then deferring less important features for later using lazy loading to request and display content only when the user gets to or interacts with it. And by pre-loading features, the user is likely to interact with next.
Smoothness and Interactivity
- Improving the perceived performance of a site through skeleton interfaces, visual loaders and clear indication that something is happening and things are going to work soon.
Performance measurements
- Tools and metrics to monitor performance and validate up to station efforts. The thing to keep in mind here is that not every performance optimization will fit your solution and needs.
- Browser tools measuring performance include Lighthouse (Chrome), Network monitor, Performance monitor. There are also hosted third-party tools like PageSpeed Insights (Google), WebPage Test, GTMetrics(actually Lighthouse) which help measure performance.
- Key indicators that these tools use ro describe the performance are:
  - First paint- The time it takes before the user sees changes happening in the browser. Largest Contentful Paint (LCP)- The time it takes before the user sees content, so text images, something else in the browser.
  - First Meaningful Paint (FMP)- The time it takes before the user sees content that is actually meaningful. So when above the full content and web fonts are loaded and the user can derive meaning from what they are seeing.
  - Time To Interactive- The time it takes before the content has finished loading and the UI can be interacted with so the user can actually click on buttons, fill forms or do whatever else is going to happen on the site.

The longer it takes for a site to hit each of these points, the higher the chance of the user either getting annoyed or abandoning the user experience altogether. So good performance is better for your visitors, better for you because you don't have to pay as much for your hosting, better for your Google rankings, and finally, better for the environment.

Critical Rendering Path (CRP)

To understand performance optimization, you first need a solid understanding of how typing something into the address bar of a browser results in the page being rendered in the viewport.

It all starts with the browser sending a request for some site.com to its Internet Service Provider.

The ISP then sends the request immediately to a DNS domain name service, a phone book for the web which maps the website you're seeking to the address for the website.

This DNS lookup is done for each unique hostname. So if the site you're requesting is using externally hosted fonts, or JavaScript libraries, or images, or videos or other services, this DNS lookup happens for each of those different services. Anytime there's a new domain name, a new DNS lookup have to take effect. This is the first major performance bottleneck.

To do away with some of this performance overhead, the domain name to IP address association will probably be cached at numerous different steps, your ISP will cached as information, it will also likely be cached in your router and on your computer. That way when you send a request to the same domain you requested before, instead of having to go through the whole DNS lookup again, we're just pulling a cache from somewhere closer to the computer, but that also means if the DNS has changed in the meantime, you'll get an incorrect address pointing and things won't work as expected.

Once the IP address is established, the browser and server now perform what's called a TCP handshake, where they exchange identity keys and other information to establish a temporary connection and working relationship. This is also where the type of connection is determined this is there's a regular HTTP connection or is it an encrypted HTTPS connection? If the latter, encryption keys are exchanged and if both the browser and the server support it, the transaction is updated from HTTP 1.1 to HTTP two, which provides substantial performance enhancements.

We now have a connection and everything is ready to go. At this point, the browser sends an HTTP GET request for the resource it's looking for. This initial GET request will be for whatever the default file on the server location is, typically index.html or index.php or index.js or something similar to that.

The time it takes for the browser to finally receive the first byte of the actual page it's looking for, is measured in time to first byte or TTFB. The first piece of data called the packet that the browser receives is always 14 kilobytes, then the packet size doubles with every new transfer. That means if you want something to happen right away, you need to cram it into those first 14 kilobytes.

The browser now gets a file an HTML document, and it starts reading it from top to bottom and then parsing that data. This means the HTML is turned into a DOM tree, the CSS is turned into a CSSOM tree and object model for the CSS of the page, which makes it possible for the browser to render the CSS for JavaScript to interact with it. And as the document is parsed, the browser also loads in any external assets as they are encountered. That means anytime it encounters a new CSS file, or reference to anything else, it'll send a new request, the server responds by sending the request back, then it gets placed into the system, and the browser starts rendering that as well.

In the case of JavaScript, though, the browser stops everything else and waits for the file to be fully downloaded. Why? Because there's a good chance of JavaScript wants to make changes to either the DOM or the CSSOM or both. This is what's known as render blocking, whatever rendering was happening, stops and is literally blocked for as long as the browser is waiting for the JavaScript to be fully loaded and then fully executed. Once all of this parsing is done, the rendering can begin in earnest and here the browser combines the DOM and CSSOM to style, layout, paint and composite the document in the viewport.

The metric time to first Contentful paint refers to how long it takes for all of this to happen. What's important for our purposes is to remember what's actually happening, that way we can identify bottlenecks and add performance enhancements to get past them as quickly as possible.

Optimizing the CRP

When you interact with content on the web today, you're using one of two different versions of the HTTP protocol, either the old HTTP/1.1 or the more modern HTTP/2. Which protocol version is in use has a significant impact on the performance of the site. In HTTP/1.1, all files requested by the browser are loaded synchronously, one after the other. So a typical HTML page with two style sheets, a couple of images, and some JavaScript would require the browser to first load the HTML document, then the CSS files, then the JavaScript files, and finally the image files one after the other. This is slow, inefficient, and a recipe for terrible performance.

To work around this obvious issue, browsers cheat by opening up to six parallel connections to the server to pull down data. However, this creates what's known as head of line blocking, where the first file, the HTML file, holds back the rest of the files from downloading. It also puts enormous strain on the internet connection and the infrastructure, both the browser and the server, because you're now operating with six connections instead of one single connection.

In HTTP/2, we have what's known as multiplexing. The browser can download many separate files at the same time over one connection, and each download is independent of the others. That means with HTTP/2, the browser can start downloading a new asset as soon as it's encountered, and the whole process happens significantly faster.

Now, for HTTP to work, a few key conditions need to be met. Number one, the server must support HTTP/2. Number two, the browser must also support HTTP/2. And number three, the connection must be encrypted over HTTPS. If any of these conditions are not met, the connection automatically falls back to HTTP/1.1. So bottom line, for instant performance improvements with minimal work, get an SSL certificate for your domain and ensure your server supports HTTP/2.

Identifying which bottlenecks cause performance issues for you is the key to performance optimization.The server itself can contribute to poor performance.

The next bottleneck is the connection made between the browser and the servers hosting the files necessary to render the page. For each of these connections, that whole DNS and TCP handshake loop needs to take place, which slows down the whole process.

How many files are downloaded and in what order those files are downloaded has an impact on performance.

Caching(or storing of assets) is also one of the methods for performance optimization. This can be done on the server, on the CDN or in the browser.

Caching on the Server

If you're running a site relying on server-side rendering, meaning each page or view is generated on the fly by the server when it is requested, caching may provide a huge performance boost. By enabling caching, the server no longer has to render the page every time the page is requested.
Instead when the page is rendered, a snapshot of that page is created and then stored in the server cache. The next time a visitor then comes to the site, there'll be handed at this stored cached snapshot instead of a freshly rendered page. This is why static site generators have become so popular: they produce pre-rendered cacheable static pages and bypass the entire CMS service side rendering problem. The challenge with this type of caching is in dynamic features they have. Like every time a new comment is added, the cache needs to be cleared, and then the page has to be regenerated. Even so, caching should be enabled for all sites relying on server-side rendering because performance benefits are so significant.

Caching on the CDN

CDNs are effectively external caching services for sites. CDNs can also do edge computing. Here, the CDN renders the page when requested and then caches it itself. This edge approach works well with modern static site generators like Gatsby and all JavaScript based site generators and frameworks because they serve up static assets by default, and are built to work in this modern web architecture.

Caching in the browser

There are two main things we can do here. One, store existing assets. So if the visitor returns to the site it already has all the information cached in the browser and two, push files to the browser early so by the time the browser requests the file, the files that are already sitting in the cache. All browsers do some level of caching automatically and also we can then instruct the browser on exactly how we want to handle caching of our assets. For assets that are unlikely to change such as main style sheets, JavaScript, and other images, long caches makes sense. For assets that are likely to change over time, short cache durations, or no cashing at all may make more sense.

To ensure new and updated assets always make it to the visitor. We can use cache busting strategies like appending automatic hashes to file names or we can rely on the server itself to document the file name on file date for each file, and then do the caching automatically. You can also split up CSS and JavaScript files into smaller modules and when you update something in CSS or JavaScript, instead of having to recache an entire style sheet for an entire site, you're just recaching the module that has that update.

PRPL and Performance Budget

To achieve the best possible performance for your website or application always keep the PRPL pattern in mind.
This is an acronym that stands for:
Push or preload important resources to the browser using server push for the initial load and service workers in the next round, the application will run faster.
Render the initial route as soon as possible by serving the browser with critical CSS and JavaScript, the perceived performance of the application will be improved.
Pre-cache remaining assets so they are available when the browser needs them.
Lazy load all non-critical assets so they only load when they are actually needed, such that we reduce the time to initial load and save the visitor from wasting their bandwidth on assets they will never use.

The number one metric that determines the performance of your site or app is its weight.
Performance budget gives you a metric to measure every new feature against and a tool to use when hard decisions need to be made. A performance budget may include limits on the total page weight, total image weight, number of HTTP requests, maximum number of fonts or images or external assets, etc.
We now have tools that we can integrate into our build processes like Webpack's performance options, which you can get directly inside Webpack and Lighthouse's light wallet, which gives you the ability to test your builds against the performance budget at any time to get flags anytime your images are too big or your JavaScript is too big or your CSS is too big or anything else.

Some best practice metrics for Performance budget are:

Make sure that your site meets a speed index under three seconds.
Time to interactive is under five seconds.
The largest contentful paint is under one second
The max potential first input delay is under 130 microseconds.
The maximum size of the Gzipped JavaScript bundle is under 170kb.
The total bundle size is under 250kb and that all of this happens on a low powered feature phone on 3G.

Now these performance budget metrics are severe and really difficult to hit. They're also the metrics being used by tools like Lighthouse to test for performance.

So the question here comes how to create a realistic Performance Budget?

Build seperate performance budgets on slow networks and laptop/desktop devices on fast networks.
Do performance audit.
Set resonable goals based on audit.
Test production version against perfomance budget.
Do a competitor performance audit: make your performance goal better than your competitor.
Test all work against Performance budget though Performance budget are unique to each project and will change overtime.

Part- II

Managing UI State in a React App

Bipul Sharma — Fri, 16 Jul 2021 11:27:56 +0000

Introduction

UI State is the state that is only useful for controlling the interactive parts of our React app. The other state being Server-cache(State's stored on the server, and we store in the client for quick-access: like user data).

useState is a Hook that lets you add React state to function components.

Lifting State Up

If we have 2 sibling components that both need same state(or functions/methods), we need to lift that state to the least parent component and pass the data down to the components that need through props.

Prop Drilling

Now, if some component far away in the component tree needs the state, you need to lift the state all the way to the top and pass props to all intermediate components to get the data down to the component that actually needs it.

This is what is called prop drilling- passing data from one part of the React Component tree to another by going through other parts that do not need the data but only help in passing it around.

Lets take a simple example:

Here, UserPanel component and UserPanelContent component are intermediate components acting as tunnels to get the data down to the Welcome component that actually needs the data.

Using Composition to avoid Prop Drilling

Instead of making components that render components and wiring props everywhere like this, you could compose things together through children props.

Using children prop increases the ability to compose i.e it makes the UserPanel costomizable(such that you can choose what goes inside the Panel) and also it eliminates prop drilling.

There are various situations where prop drilling can cause some real pain in the process of refactoring especially.

Context

Context is designed to share data that can be considered “global” for a tree of React components, such as the current authenticated user, theme, or preferred language. If you only want to avoid passing some props through many levels, component composition is often a simpler solution than context.
~React docs

If 3 components require data(or methods), we choose a common parent and wrap it in a provider and then we wrap the components that require data/method in a consumer.

Taking example from the previous code:

Here, the useContext hook gives us an extra, much prettier, way to consume context.
If you have a really large application and you have the entire thing surrounded by a Context Provider anytime you make a change to that state it is going to render everything that is nested under the provider which can make interactions feel slow. Adding useMemo increases performance which says hey if these values dont change dont render these components.

Outro

Many UI state managment tools are available like Redux, Mobx, Recoil, Jotai, XState which may be used but React is all you need to manage your applications UI state most of time.

DEV Community: Bipul Sharma

Web Performance Optimization- II

About

Image Optimization

JavaScript Optimization

CSS Optimization

Web Performance Optimization- I

Introduction

Critical Rendering Path (CRP)

Optimizing the CRP

PRPL and Performance Budget

Managing UI State in a React App

Introduction

Lifting State Up

Prop Drilling

Using Composition to avoid Prop Drilling

Context

Outro

Further Reading