Web Performance Optimization- needs, benefits, step by step process

Why Performance needs to be improved?

1. User Experience: We don’t like to wait, it simply demotivating to us. Previously we used to scold IRCTC website.

2. Productivity: If any website or software is running slow, it kills productivity of the team.

3. Profitability: Faster application can serve fast and larger audience hence generates profitability.

4. Operational Costs: If any website or software is running slow, it kills productivity of the team. It increases operational costs.

5. Google ranking also happens based on performance

Performance Monitoring:

Core Web Vitals are a set of metrics to measure and improve user experience on web. They focus on three major aspects: loading performance, interactivity and visual stability.

(Loading)

1. LCP (Largest Contentful Paint) — Measures the time it takes for the most of the contents of webpage to load and be visible. If it takes less than 2.5 seconds, then it is considered good for user experience.

(Interactivity)

2. FID (First Input Delay) :

It measures the time when a user first interacts with the site and to the time user gets some response or better to say browser responds to the interaction.

INP:

It measures the delay between a user interaction and the next time the browser paints. Evaluates the responsiveness of the page beyond the first interaction, ensuring ongoing interactions are also smooth

(Visual Stability)

3. CLS (Cumulative Layout Shift):

It measures the sum total of all the individual layout shifts that occurs during entire lifespan of the page. Ensures that the visual stability of the page is maintained, reducing unexpected movement of content which can be frustrating for users.

Browser Centric Metric vs User Centric Metrics

1. Time to First Bite (TTFB): Measures the time taken from the user’s request to the first byte of the page being received by the browser.

2. Network Request: Time taken for a network request to be completed.

3. DNS: Time taken to resolve the domain name into an IP address. It basically measures the initial connection set up time.

4. Connection Time: Time taken to establish a connection with the server. Parameters like SSL handshake time effects the connection time.

5. Dom content loaded: Measures the time when the initial HTML document has been completely loaded and parsed. Resources may still be loading.

6. Page Load Event: Measures the time when everything on a page is fully loaded.

Uses:

1.Technical aspects of page loading and rendering

2. Identifying technical bottlenecks and optimizing loading process

3. Set performance metrics for key technical metrics

User centric Event:

1. First Contentful paint (FCP): Measures the time from the start of the page load to when any part of the page’s content is rendered on the screen. It indicates when the user first starts consuming the content.

2. Largest Contentful Paint (LCP): It measures the time it takes for the largest content element to be visible.

3. First Input Delay (FID)

4. Interaction to next paint(INP)

5. Total blocking Time (TBT): Measures the total time, during which the main thread is blocked, preventing user interactions. It affects the page responsiveness.

6. Cumulative Layout Shift (CLS)

Uses:

1. Directly measures user experience and perception of performance
2. Includes metrics like FID and INP to evaluate responsiveness.
3. Prioritizing and ensuring better user experience.

Tools for measuring performance:

1. Lighthouse, 2. WebPageTest, 3. Google PageSpeed Insights

Network Optimization:

Critical Rendering Path (CRP): The CRP is the sequence of steps the browser takes to render a webpage.

· Minimize the number of critical resources: Identify and reduce the number of critical resources to speed up the initial rendering.

· Optimize the order of resource loading: Ensure that critical CSS and JavaScript files are loaded first.

· Reduce the critical path length: Minimize the size of critical resources by using inline small CSS, minimizing CSS, and JavaScript files.

Minimize HTTP requests: Factors like connection handshake, Browser limit per domain (6–10 max parallel call can be made) can slow down the page load time.

Solution: Using Inline CSS, Inline JS, Base64 images, SVG images,

Async loading of JS:

Loading JavaScript files asynchronously or deferring them can prevent them from blocking the rendering of the page

Async: This script is executed as soon as it is downloaded.

Defer: The script is executed after the html is parsed.

Avoid Redirection: Minimizing redirects can reduce latency and improve load times.

Resource Hinting (preload, prefetch):

preconnect: The preconnect resource hint tells the browser to open a connection to a domain or subdomain. We can use to connect to a domain in advance for heavy tasks like loading images.

dns-prefetch: Resolves domain name early.

preload: Loads resources early in the loading process.

prefetch: Load resources which are needed in near future with low priority. We may not need the resource immediately, maybe it is needed in some another page.

prerender: Loads entire page and all its dependency in the background. It is in the cache already rendered.

Fetch Priority: Setting fetch priorities helps the browser prioritize important resources.

Early Hints: HTTP/2 103 Early Hints allow servers to suggest resources the client should start fetching before the main response arrives.

HTTP upgrade methods (HTTP1 vs HTTP2 vs HTTP3 ):

· HTTP/2: Multiplexing, header compression, and server push improve performance.

· HTTP/3: Uses QUIC protocol for faster and more reliable connections.

Difference between HTTP/1, HTTP/2, HTTP/3:

Compression (brotli/gzip):

 Compression algorithms like gzip and Brotli are essential for reducing the size of web resources, which helps improve page load times and overall web performance.

It can be applied during runtime or during build phase.

Build Time Compression is best suited for static contents. Run time compression is best suited for dynamic contents.

Build Time Compression Advantages:

1. Reduced Server load

2. Consistent Compression

3. Improved Performance

Run time compression advantages:

1. No storage overhead: Only the uncompressed version of the file needs to be stored on the server.

2. Dynamic Content

Disadvantages:

1. Heavy resources can slow down the server as it impacts CPU performance.

2. Variable compression quality.

HTTP Caching : Proper caching strategies reduce the need to fetch resources again, speeding up load times.

We can use Cache-Control headers and ETags.

Caching using Service Worker: Service workers can cache resources and serve them from the cache, improving load times and enabling offline functionality.

Rendering Pattern:

CSS- render blocking, JS — parsing blocking

CSR: HTML ->JS/CSS/IMG ->API ->Render-> Hydration

· Initial HTML Load: The browser loads a minimal HTML document.

· Fetching Assets: The HTML document includes links to JavaScript, CSS, and image files, which are then fetched by the browser.

· API Calls: Once the JavaScript is executed, it makes API calls to fetch data.

· Rendering: The JavaScript uses the fetched data to render the content in the browser.

Hydration: Adding a set of listener when the JS DOM tree is ready to make the page interactive is known as Hydration.

Client Side Rendering

1. Dynamic — Server Side Rendering

2. Static — Static Side Generation

SSR: HTML-> API(JS/CSS) -> Render -> On browser side, Hydration

· Initial HTML Generation: The server generates the complete HTML for the requested page.

· Fetching Assets: The HTML document includes links to JavaScript, CSS, and other assets, which are then fetched by the browser.

· Rendering on the Server: The server renders the page’s HTML content using the fetched data.

· Sending HTML to Client: The server sends the fully rendered HTML to the client.

· Hydration: On the client side, JavaScript takes over to make the page interactive by attaching event listeners and re-rendering components if necessary.

Heavy lifting is done on the server side.

Disadvantage: Doing much heavy work on the server side may make client side and user wait for longer time which is not good for user satisfaction.

SSG: Build (API/JS/CSS) -> Static Site -> On Browser Side, HTML à Hydration

· Build Time: The site is built once, fetching necessary data and generating static HTML, CSS, and JavaScript files.

· Static Site: The generated static files are deployed to a server or a CDN.

· Initial HTML Load: The browser loads the static HTML, CSS, and JavaScript files.

· Hydration: On the client side, JavaScript takes over the static HTML to make the page interactive by attaching event listeners and re-rendering components if necessary.

When to choose SSG:

1. When you have static content that doesn’t change often

2. When you need cost-effective solution

When to choose SSR:

1. When you have dynamic content that changes frequently

2. When personalization or user-specific content is important.

Cons of SSR:

1. Costly, 2. Technical Complexity

Ref: neoGCamp, namastedev, chatGpt