My web performance experiment - a speed field trial

by Marc Radziwill | April 19, 2020 | 7 minutes to read

The experiment is a field trial on how to improve the performance of your web page after the implementation is done.

Web performance workshop

devcademy by Marc Radziwill

Web Performance is still one of the most underrated topics in web development. Even though it can help us, our companies and customers with their and our business, make our website more accessible for people with a slow network and has a significant impact on a sustainable internet.

become a web performance expert

In my career as a developer and especially since I do performance workshops for companies and dev teams, I often recognize the same with performance problems. No matter how big the team or the project was, after some time, the application or website suddenly started being slower.

I haven't found any reasons why this happens because the developers at least on my projects had excellent knowledge and experience. Maybe it is because technical user stories are not accessible. But even if they are, it is a difficult task to stay fast.

Often my customers book me for helping them to find their performance bottlenecks and teach the dev team exactly when they are finding out that their application or website is slow and they have a significant disadvantage for their business.

To keep your site up to speed is no rocket science. You just have to follow some rules. But as I want to help all my customers with my very best knowledge I've done a field trial with my website, and in this post, I describe my way of making my site faster, what I did and why I did it.

Tl;dr

The experiment is a field trial on how to improve the performance of your web page after the implementation is done. I want to speed up the page loading, the response time.


  1. What is Svelte?
  2. What is the tech stack to be optimized?
  3. The progress of implementation
  4. Making my site fast using web performance optimization techniques
  5. Takeaways for web performance
  6. What's next?

What is a web performance experiment?

I am self-employed for many years, and I've worked on many projects with many different clients as a developer, a technical project lead, or I was a dev team member responsible additionally responsible for any performance issues, training or workshops and other performance-related topics.

Last year I had decided to take another step in my career and also offer web performance workshops for developers, dev teams and companies that are not related to my current projects.

So far, so good. I needed a new website, and I thought I needed it fast. To be fast is one of the most requirement of nearly any of my projects.

We, as developers should deliver fast and with high quality. That was the moment the idea of my "performance experiment" came to my mind, and I decided to try it.

I usually set up my projects, including a performance budget to have an eye on my speed and some more performance-related tasks. This time I made it different.

I said to myself, first I am going to implement my website or better said my MVP, and after that, I measure my performance, make a comprehensive analysis of the page speed and apply all the rules and optimization techniques I know to speed up my site. I wanted to face the same issues and problems my clients have.

In my workshops, we often pick some parts of my client's applications that are slow and fix them. Sometimes the stakeholder needs some functionality that is just not performant, but I like to show my workshop participants how they could fix these issues.

So this time I have to apply all the advice by myself, and I have to discuss with myself if some functionality is essential or if I can get rid of it.

I was inquisitive, and I started right away.

What is the tech stack to be optimized?

But what is the tech-stack? I went with GatsbyJs and my hosting with now. I decided against any content management system and just serve my GatsbyJs website with JSON files.

If you have ever developed a site with GatsbyJs and additionally have some React experience you know, it is pretty straight forward. In no time you have some pages with content on it.

The progress of implementation

After some pages and components, I had the first more significant task. I wanted to have a multi-language website. There are many useful plugins to help us with that, but none of them fit my needs to 100%, so I used Gatsbys hook functions to manipulate the page creation.

I translated the URL and passed a context variable as the language code (en and de). Manipulating the pages worked great with Gatsbys Node API, and I was motivated how fast I got to my first results.

Like I said above performance wasn't my number one priority and I didn't want to reinvent the wheel to safe time. So how can I save time while coding? Use libs instead of implementing the code yourself. So except for my translation implementation, I tried to use libs.

Which UI component library did I choose?

As I'm planning to hold web accessibility workshops in the future, I wanted to kill two birds with one stone and searched for a React component library with full web accessibility. After some time, I found Grommet. I liked their style as well as their icons and decided to go for it.

State management on my web page

As I already work with redux, I didn't make some new researches and npm installed it to my GatsbyJs project.

Web performance workshop

devcademy by Marc Radziwill

Web Performance is still one of the most underrated topics in web development. Even though it can help us, our companies and customers with their and our business, make our website more accessible for people with a slow network and has a significant impact on a sustainable internet.

become a web performance expert

Cookies-management

I need to inform my website visitors on how I collect data, and I need to allow them to decline any kind of tracking. As I need to remember their decision, I implemented react-cookie.

Styling - CSS, CSSinJS, Scss?

I'm not getting comfortable with the way I can apply styles to react components, so I chose styled-components for that as they were installed nevertheless via npm due to the grommet and grommet-icons packages.

Making my site fast using web performance optimization techniques

I am online! I was glad when I now --prod my site to the web. I leaned back an enjoy it. So the first part of my experiment went well.

I have a website running. Now let's go for the exciting part of it. How fast is my site? I had no clue, so I needed to measure.

In my workshops, I use some tools to measure to create detailed analyses, but I wanted to make the measurement as easy as possible. I decided to use four tools to measure. They must be free and available for all developers.

  1. Webpack Bundle Analyzer
  2. WebPagetest.org
  3. Chrome Developer Tools
    • incl. React Developer Tools
  4. Google PageSpeed Insights (Audit)

How to measure javascript performance?

Webpack Bundle Analyzer

To use the webpack bundle analyzer in GatsbyJs, I have used the gatsby-plugin-webpack-bundle-analyzer plugin. It adds the additional webpack configuration to the build process so we can view it.

Let's run this and check out the results: Webpack Bundle Analyzer

Ok as you see in the results of the webpack bundle analyzer, some libs I used are huge! All the libs are useful for me during the development, but in terms of performance, I might need to consider if I need them all. Some of them are important, while I probably can replace or remove others.

WebPagetest.org

WebPagetest.org is an excellent speed test tool to check the speed of your site. With the advanced settings, you can run multiple tests in different environments. For my site and the sake of simplicity, I ran three tests with different locations in the Chrome browser.

Chrome Developer Tools (Audit)

In this measurement, I focused on the results of the audit tab. If you want to dive deeper into the measurement with the developer tools sign up for my newsletter or check out my workshops for web performance.

To get a clear overview of my performance, I only check the performance and best practices checkboxes and run the audit with this setting. Keep in mind to use a new Chrome profile or at least an incognito window of chrome to get more accurate results.

I took my latest build a ran it...

Oh my ... 😳

The "blazing fast site" I started with is nearly half as fast as before. Check out the screenshot below. Nearly every metric is not in the optimal range.

Chrome developer tools audit

I expected a slow result, but not that slow. I felt motivated, but before I started to speed up, I did one last measurement.

Google PageSpeed Insights

The measurement with the PageSpeed Insights from Google gives you an excellent overview of your performance metrics without having any developer knowledge. For the sake of completeness, I ran my site multiple times with the Insights-tool of Google.

How to make my site faster

After measuring my site with three tools, I created tasks based on it. I started with the results of the webpack bundle analyzer. I removed any default imports of libs.

If I only need on util function from lodash, I don't need the whole package in my bundle. When I saw the results, I recognize that grommet is enormous. I still like the style of the components, but not the byte size.

So I implemented my components with a likewise style. This was probably to most work of all. Grommet does not only gives you some components, but it is also a whole theme. So every colour, font-size, border, padding of my site was defined by a theme object.

What I did was to keep the theme object and use all the defined values in my components but remove the "grommet" out of them.

After I removed grommet, I rechecked my bundle and saw that styled-components is still a dependency of grommet icons. So I could not just remove them. I don't like the way I can add styles to a component in React so I played a little with styled-components and I liked it.

But before I used the lib, I checked the size and compared it to css from the @emotion/core lib. @emotion/core was smaller at that time, so I removed styled-components, inlined my grommet icons with SVG versions and implemented @emotion/core instead of styled-components and React styles.

Next, I saw that the main-thread work is to high. As I know and because the webpack bundle analyzer told me, I used redux for my state management.

I thought about this a while. Probably I don't need a library for my state management. I already have one: React.

So I removed Redux and implemented it with Reacts context API. Not that redux is not suitable for my project; I just don't need it. After I removed unused code and libs, I started to went through my components. In nearly every component, I found some code I could remove.

Sometimes it was functionality for some fancy but not needed stuff; sometimes I could realize it on a different way with less code.

For my cookies, I used react-cookie. I like the abstraction, but it still more code that has to run and it is easy to implement a getter and setter for a cookie with plain JavaScript.

Results

In the meantime I have optimized my site and get between 98% - 99% of the common performance evaluations. It took me almost twice as long to apply all performance optimizations as to implement the website.

Takeaways for web performance

The takeaways of my performance experiment are simple to apply to future projects. Again as you read through my post, none of this is rocket science. You just have to follow some rules before starting and during your development.

  • Set up a performance budget
  • Check the bundle size of you libs
  • Can I remove or reduce my code? Can I move it to a web worker?
  • Making a site faster after you finished the development is much more complex than keeping the site fast from the beginning.

4. What's next?

If you like this article, smile for a moment, share it, follow me and subscribe to my newsletter.

Cheers Marc

Discuss on Twitter

stay up to date!

Sign up for my free newsletter and get your dose of technical education and inspiration.