Speeding Up a Front End No One Could Touch: A Performance Engagement for Visit California
Visit California’s platform was working for its visitors and costing its editors an hour a sentence. Same site, faster build, lighter pages.
The work
The Challenge: A Site Visitors Loved, and an Hour to Publish a Sentence
Visit California operates the state’s official tourism platform — editorial content, trip inspiration and local recommendations, for a state that drew nearly 270 million visitors in 2023. The audience-facing site was working: the design, the features and the editorial register were all performing. The cost was in operating it. Publishing a single sentence could take over an hour, builds failed often, and the page a visitor loaded weighed 25 MB. The brief ruled out the usual fix — the front end had to stay exactly as it was.
The Strategy: Rebuild the Pipeline Under a Front End That Could Not Move
Rebuild the data layer and the build pipeline underneath a front end no one was allowed to touch.
- JSON API in place of GraphQL. The Drupal module behind most of the pipeline problem, replaced with an approach two prior engagements had already proven.
- An incremental build that is actually incremental. Gatsby Source Drupal plus the Gatsby Integration module, so a content change pulls the content that changed.
- Image derivatives off the deployment path, generated ahead of time on the back end instead of during every build.
- Guardrails in the CMS, so future uploads cannot quietly undo the page-weight work.
The Outcomes: Same Site for Visitors, a Different System for Everyone Else
Same site for visitors. A different system for everyone else.
- Engagement | Desktop home page 25.41 MB → 3.61 MB, down 85.79% | Mobile Core Web Vitals score 3 → 31, Speed Index 22.9s → 9.5s
- Intelligence | Content updates from hours or days to minutes | Builds from frequent failures to consistent successful deployments
The detail
Why it mattered
- A site that worked, and cost hours to operate. The design, the content features and the editorial register were all performing. The cost sat behind them: a back end that made every editorial change expensive for the team running the platform.
- A single sentence took over an hour to publish. The GraphQL module between Drupal and the Gatsby front end was the source of most of the data-pipeline problem, and builds frequently failed outright — so the cost of a typo was an hour and a coin flip.
- The incremental build was not incremental. The Gatsby Source GraphQL plugin pulled and refreshed the entire dataset on every content update, which is the opposite of what an incremental system is for.
- Image processing sat on the deployment path. Derivatives were generated during deploys, so every build reprocessed every image. Oversized images then doubled the cost at the other end, for the mobile visitors who are most of the traffic.
- And the front end could not move. Most architecture overhauls ride along with a redesign. This one had to leave the audience experience exactly where it was — same site for visitors, different system entirely for the people running it.
The call and the build
- GraphQL out, JSON API in. Two prior engagements had run JSON API on similar architectures with strong results. Migrating the data layer sped the movement between back end and front end and took content updates from hours to minutes.
- The right Gatsby plugin, and the back end configured to match. Gatsby Source Drupal replaced Gatsby Source GraphQL, with the Gatsby Integration module configured against JSON API so incremental builds pulled only what had changed rather than everything.
- Image derivatives moved off the deploy. The JSON API Image Styles module generates sizes ahead of time on the back end, so deploys no longer process images at all.
- Guardrails, so the win does not erode. Drupal sizing limits were configured to stop future uploads undoing the optimization.
- 75,000 lines touched, 23 front-end templates updated. Deprecated code removed, and the page-creation code rewritten to eliminate static queries that had been running thousands of times per build.
What moved
- Desktop home page: 25.41 MB → 3.61 MB. Down 85.79%. The mobile home page went 12.07 MB → 3.62 MB, down 70.01%.
- Mobile Core Web Vitals: score 3 → 31. Total Blocking Time 8,980ms → 2,140ms, and Speed Index 22.9s → 9.5s. Mobile is where the majority of this audience arrives.
- Desktop Core Web Vitals: score 38 → 63. Total Blocking Time 1,600ms → 420ms, Speed Index 3.9s → 2.6s.
- Content updates: hours or days → minutes. And builds went from frequent failures to consistent successful deployments, which is the half of this the editorial team feels every day.
- Full builds 64 minutes; incrementals 42; failures 52% → 0%. The unexplained failure rate — the coin flip on every publish — went from more than half of builds to none on the record.
- The site looks the same. Which was the brief. For a state tourism platform serving the largest tourism economy in the country, the result is a platform performing at the level its visitor numbers and editorial cadence already required.
Web performance optimization questions
Can site performance be fixed without a redesign?
Yes — this engagement had to. Visit California’s audience loved the site, so the front end stayed exactly as it was while the data layer and build pipeline underneath were rebuilt. Desktop home-page weight fell from 25.41 MB to 3.61 MB with no visible change.
Why do static site builds take hours?
Usually because nothing is truly incremental. At Visit California, the API between the CMS and the front end pulled and refreshed the entire dataset on every content update, and builds failed more often than not — an unexplained failure rate of 52%. Replacing GraphQL with JSON API and configuring truly incremental builds took content updates from hours or days to minutes, with the failure rate at zero on the record since.
What causes heavy page weight on editorial sites?
Usually images. Visit California processed image derivatives during deploys — every build reprocessed every image — and oversized uploads doubled the cost on the mobile visitors who are most of the traffic. Derivatives moved to the back end, generated ahead of time, with CMS sizing guardrails so future uploads cannot quietly undo the work.
How much can Core Web Vitals optimization improve a site?
For the Visit California engagement by Pare & Co: home pages down 86% on desktop and 70% on mobile, mobile Core Web Vitals from 3 to 31 with Speed Index from 22.9s to 9.5s, full builds at 64 minutes and incrementals at 42, build failures from 52% to zero — and a site that looks exactly the same, which was the brief.
Client leadership
Jack Hartman
Jack Hartman came up through agencies in New York and Philadelphia. He has led performance work where the constraint was a front end the team could not touch.