setting our site(s) on web vitals

introduction

at networkworld-digital.com , we are constantly striving to improve the user experience on our site. from ui updates to launching an app on the ios and google play store, our day to day is focused on consistently enhancing the accessibility and reach of our product. in response to the introduction of web vitals from google , we set our site on a new objective: improving performance. web vitals introduces a standard measurement of user quality experience with a few metrics: loading (lcp), interactivity (fid), and visual stability (cls). web vitals is not only valuable for providing critical user experience data, but it is also a data point used by google to determine your site’s ranking in their algorithm. 

problem & methodology

to improve the site experience and performance, we focused on two of our biggest problems, shifting elements on the page and network request size. to accurately measure the impacts of our changes, we opted to make small incremental changes. we also wanted our changes to have the most considerable impact with minimal effort. taking a look at our deliverables, one of our most oversized packages, material-ui, had an overall parsed js size of 204.33kb. this package, along with some of the script evaluation time that material-ui introduces, led us to focus on removing material-ui and switching to tailwindcss .

our largest package, material-ui, had an overall parsed js size of 204.33kb.

204.33KB parsed material-ui
our material-ui bundle resulted in an additional 204.33 kb of parsed js
9.4KB of CSS
css included in material-ui resulted in an additional 9.4kb of styles loaded

another factor in our decision to remove material-ui was that we had moved further away from most of the base material-ui designs. we were spending quite a lot of development time fighting against the default material-ui styles, and we determined that switching to something more flexible would save us time in the long run. 

actions

removing material-ui from our stack used quite a bit of development time; however, the payoff was worth it as we can now quickly design and implement new features to the site. to start, we looked at components that were used most often around the site and rebuilt them using tailwindcss. this helped us in two ways, 

  1.  we were able to confirm that removing material-ui would have a positive impact on site performance. 
  2. we could see a few immediate gains after replacing these common components.

along with removing material-ui, we also optimized third-party scripts, images, and data sent to the frontend.

Answers - Material vs. Tailwind
 answers – material vs. tailwind

what we learned

with the focus on web vitals, we had to take a few things into consideration that never came up before during our development process. this had led to a few changes in what we consider when creating and implementing a new feature on our site, such as math solution functionality. after the big push for performance gains, we are now more focused on implementing new features while maintaining and improving site performance. another lesson is that while frameworks can be great for getting something off the ground, they could actually cause development pains further along during the life of the application.  as we continue improving answers with new and exciting features, we will always be on the lookout for performance gains that will improve user experience and overall satisfaction.