Optimizing Springboard's Website Performance · Project

As a part of the growth team at Springboard, I worked on maintaining and creating new features for the marketing website, www.springboard.com. This website was built using Gatsby (a static site generator), React, and Storyblok as a headless CMS.


We also supported some university partnership websites, such as usfbootcamps.com, through the same repository.


Initial Performance Analysis


By conducting page performance tests, we realized that our website’s performance, especially on mobile devices, was not great. On mobile, our overall performance score was around 30, while on desktop, it was better at around 50.

We decided to work on improving the website’s performance, and this task was led by me. The goal was to:

  1. Identify various factors affecting website performance.

  2. Prioritize and suggest optimizations.

  3. Create a project plan with milestones and deadlines.

  4. Execute these optimiztions and measure their impact.


However, there was a challenge—about two years ago, we had already done a performance optimization project. Many well-known optimizations (such as encoding, caching, and code splitting) were already implemented. I needed to be more thorough in identifying and executing improvements.


Learning About Website Performance Optimization


Since this was my first time working on a deep performance optimization project, I decided to educate myself first.


My go-to resources were:


One key insight from my research was that while there is a definitive gold standard for website performance, there are innumerable ways to stray from it. My task wasn’t simply to apply a checklist of fixes—it was to uncover the unique factors that had compromised our website’s performance and then correct them.


Understanding Core Web Vitals


To measure the performance of our website, we focused on Core Web Vitals, especially:

We primarily used PageSpeed Insights for performance measurements, supplemented by other tools when needed.


Fixing the Critical Rendering Path


The critical rendering path is the sequence of steps the browser takes to render a page. The goal is to minimize the time it takes for the page to be usable.


I started by analyzing network calls in Chrome DevTools, looking for bottlenecks in the network waterfall. Additionally, I manually reviewed the initially rendered HTML to spot optimizations.


Network waterfall in Chrome DevToolsNetwork waterfall in Chrome DevTools

Key Optimizations


1. Fixing CSS Duplication


I noticed that our CSS was being fetched twice—once inline in the HTML and again as an external CSS file. Fixing this was a quick win.

Additionally, I installed the Gatsby PurgeCSS plugin to remove unused styles. This improved the PageSpeed Insights score by 1-2 points.


2. Optimizing Font Loading


To improve FCP and LCP:

These changes improved our mobile PageSpeed score by 5 points and desktop by 3 points. Such a large change was actually unexpected!


3. Implementing an Intercom Facade


We had an Intercom widget for customer support, but it was slowing down the page. To fix this, we installed a facade—a static placeholder image that loads the widget only when hovered over or when network activity is idle.

This optimization improved the PageSpeed score by 3 points.


Intercom FacadeIntercom Facade in action

4. Removing Unused Third-Party Scripts


Our marketing pages used many third-party scripts—analytics tools, tracking pixels, and others. I:

  1. Went through every network request in Chrome DevTools.

  2. Created a spreadsheet documenting all third-party scripts.

  3. Collaborated with other teams to identify and remove unused scripts.

This cleanup resulted in noticeable performance improvements.


TreemapTreemap of all scripts on the website. The 2 largest scripts are actually third-party scripts!

5. Offloading Third-Party Scripts with Partytown


We implemented Partytown to move non-critical third-party scripts to a web worker. This added 6 points to our PageSpeed score.


6. Fixing a B2U Module Import Issue


Some B2U-only modules were loading on B2C pages due to an incorrect named import. Fixing this improved our score by a couple more points.


7. Implementing Gatsby's Partial Hydration


We experimented with Gatsby's Partial Hydration (which works similarly to Astro’s Island Architecture). It allows marking only interactive components for hydration, reducing JavaScript payload and execution.

I left Springboard before measuring its impact, but my colleagues later reported an additional 4-point improvement.


Final Results


Through these optimizations, we improved our mobile PageSpeed Insights score from 30 to 50. Other metrics like FCP and LCP also improved significantly, making for a much better user experience.