Improving the Performance of a Real Web App (Part 3) - Analyze Performance Data

This is the third part of our series on improving the performance of a real web app. Here I talk about The Analyze Performance Data.

Each part of the solution:

1. Determine Your Key Perfomance Metrics (Part 1)
2. Use Tools to Measure Performance Metrics (Part 2)
3. Analyze Performance Data (Part 3)
4. Implement Optimizations (Part 4)
5. Measure Performance Improvements (Part 5)

Introduction

With the metrics and tools in mind, we can carefully and thoroughly analyze every aspect of our application. We can look at the data from different angles and perspectives, and gain a deeper understanding of how our application is performing. This in turn can help us identify areas where we can improve, and come up with effective strategies for doing so. By taking a meticulous and data-driven approach to analysis, we can ensure that our application is always optimized for success.

Google Lighthouse

As we can see in these charts, the performance was really poor. The range between the minimum and maximum values is from 0 to 100, and we are getting almost the minimum value.

Metrics

Google Lighthouse

• First Contentful Paint 6.5 s
• Time to Interactive 14.9 s
• Speed Index 10.0 s
• Total Blocking Time 1,750 ms
• Largest Contentful Paint 15.0 s
• Cumulative Layout Shift 1.001

This tool identifies the main problem and provides a possible solution that we can follow.:

• Preload Largest Contentful Paint image 6.83 s
• Reduce unused JavaScript
• Serve images in next-gen formats
• Properly size images
• Efficiently encode images
• Minify JavaScript
• Serve static assets with an efficient cache policy
• Reduce JavaScript execution time
• Minimize main-thread work

PageSpeed

The pagespeed is not set up with the necessary cookies to make requests. Therefore, we can only evaluate the first load and initial downloads to determine if they are good or not.That's why our notes are a little bit bigger.

Metrics

• First Contentful Paint 7,5 s
• Time to Interactive 13,0 s
• Speed Index 8,7 s
• Total Blocking Time 1.360 ms
• Largest Contentful Paint 8,0 s
• Cumulative Layout Shift 0

This tool identifies the main problem and provides a possible solution that we can follow:

Reduce unused JavaScript

To decrease network activity byte consumption, reduce unused JavaScript and defer script loading until they are needed. Learn more. LCP If you're not server rendering, split JavaScript bundles with React.lazy(). Otherwise, split code using a third-party library such as loadable-components.

Global file, and app.js:

01:
URL: chuck.app.js 
Transfer size: 675,6 KiB

02:
URL: chuck.main.js 
Transfer size: 462,6 KiB


It is import in a global file,
but was not part of my project: 

01:
URL: …/club-web-components/
Transfer size: 235,7 KiB

02: 
URL: error-state.svg
Transfer size: 8,0 KiB

03:
URL: Hours/Hours.jsx
Transfer size: 2,2 KiB        

Conclusion

I realized that the project was using JavaScript and pages from other projects. Additionally, a large SVG file was imported but never actually used. It is clear that there is a problem that needs to be solved.

GTmetrix

Initially, I was puzzled when I checked GTmetrix and saw that it indicated my website was performing exceptionally well. Nonetheless, when I cross-checked these results with other tools that I have used in the past, I noticed that they reported different values. I was unsure how to reconcile these discrepancies, and I began to suspect that perhaps each tool measured different aspects of my website's performance.

Metrics

• First Contentful Paint 645ms
• Time to Interactive 645ms
• Speed Index 776ms
• Total Blocking Time 0ms
• Largest Contentful Paint 645ms
• Cumulative Layout Shift 0

This tool identifies the main problem and provides a possible solution that we can follow:

In this case, I have identified that the size of the JavaScript files is large and needs to be reduced.

Bundle Analyzer

Here, we have a global view of all applications, as well as separate pages:

When we look at the dependency chunk, we get a big file of almost 6MB:

When we look for the app.js file, we can see that our count increases by more than 3MB.

Conclusion

After carefully reviewing the output of this tool,I have concluded that my main problem is about the size of JavaScript files. In order to solve this issue, I plan to explore a number of different techniques, including code splitting, tree shaking, and lazy loading. By implementing these techniques, I hope to reduce the size of my JavaScript files while still preserving their functionality and efficiency.

Next Step

After Analyze Performance Data, the next step is Implement Optimizations. This is covered in Part 4 of the series.