How Tag1 Improved Performance and Reliability for the Greater London Authority’s Drupal Platform

The Greater London Authority (GLA) relies on London.gov.uk to deliver essential information to residents every day. But the platform's Drupal setup had grown increasingly slow, affecting everything from page load times to how quickly editors could publish high-priority updates. With delays impacting both the public and internal teams, GLA needed a reliable way to stabilise performance and improve responsiveness.

Tag1 joined the effort to address these issues, bringing its experience in complex Drupal environments. The team focused on performance optimisation, load testing with Goose, and detailed tracing through Gander, while also improving database behaviour, caching, and infrastructure configuration. Together, these changes made London.gov.uk significantly faster and more dependable for residents and editors alike. The original case study detailing this work is available on Tag1’s website at https://www.tag1.com/our-work/gla/.

For agencies considering Drupal for multi-department or public-facing platforms, this project demonstrates how structured performance testing and targeted remediation can transform a heavy system into one that scales cleanly and remains resilient under pressure.

To understand the changes behind the scenes at London.gov.uk, The DropTimes reached out to the engineering team at Tag1 for a deeper technical perspective. Their published case study outlines a comprehensive approach involving backend clean-up, rendering improvements in Drupal, streamlined editorial workflows, and the implementation of a new monitoring system that provides the Greater London Authority (GLA) with real-time visibility into platform performance. The work reflects a coordinated effort between project stakeholders, with notable input from the GLA project team and oversight by Senior Project/Program Manager Justine Hirsch.

The problems GLA faced were not small ones. Pages that should load quickly were being slowed by huge spikes in database activity, while Drupal's menu rendering system added extra delays for both editors and residents. Heavy front-end assets made the site feel sluggish, and the editorial workflow had become increasingly difficult to manage, especially when teams needed to publish high-visibility content, such as Mayor's Question Time transcripts, on tight deadlines.

Tag1's approach combined immediate remediation with long-term structural improvements. They reduced cold-cache database queries from approximately 75,000 to 10,000 on the slowest requests through targeted menu system fixes, contributed upstream improvements to Webform and Groups modules, tuned PHP and MySQL configurations, and cut image payloads by 25 per cent via WebP optimisation.

These efforts formed the foundation for the broader performance gains the GLA recorded, including an 87 per cent reduction in application response times and a 40 per cent improvement in browser rendering across London.gov.uk. Together, these improvements led to faster page loads, fewer delays for editors, and noticeably more stable behaviour during peak traffic events.

When we asked how this reduction in database load affected the real experience of using the site, Tag1 explained:

"The slowest page loads on the site were taking 60-90 seconds to load, and the site was experiencing downtime fairly regularly. Now the slowest pages are closer to 5 or 6 seconds, and uptime has been significantly improved. Average response times as measured by CRUX are approximately 1/3rd faster, and a significant contributor to this was eliminating the slowest requests."

Much of this transformation came from how Tag1 used Goose and Gander together. Goose generated controlled waves of simulated user traffic so the team could measure improvements as they worked through the issues. Gander, meanwhile, allowed them to replicate specific scenarios-cold cache, warm cache, heavy queries-and track exactly how code changes affected performance.

As Tag1's Infrastructure Engineer, Hunter Lannon put it:

"Goose was used to track overall site performance as fixes were implemented so we could compare past performance with current performance while simulating real user traffic." - Hunter Lannon

And complementing Goose, Gander provided deeper diagnostics:

"Gander allowed us to encode specific performance scenarios (cold cache vs. warm cache requests, etc.) in a controlled environment and then track changes in metrics like total database queries or front-end asset size against changes made to the site."

The impact of these fixes showed up quickly in the data. Before the improvements, average web transaction time was 3449.75 milliseconds, and cold-cache requests triggered nearly 75,000 database queries. After deployment, the number of queries dropped to about 10,000, and Goose's load testing showed a roughly 30 per cent improvement in content editing response times. Front-end changes, including WebP conversion, reduced image payloads by 25 per cent, and Largest Contentful Paint (LCP) improved as well: 75 per cent of LCP measurements moved from under 2.6 seconds to under 2 seconds.

These backend gains also reshaped the experience for GLA's editorial teams, who had been slowed by long save and preview times and multi-step workflows. By reducing query volume, improving menu rendering, and addressing cache issues-including fixes to heavily used modules like Webform and Groups-Tag1 helped make the editorial interface far more responsive. These improvements contributed to the broader 87 per cent reduction in application response times and 40 per cent improvement in front-end rendering, allowing high-priority content such as Mayor's Question Time transcripts and press releases to be published more reliably and with faster turnaround. Editors could move through their workflows more smoothly, improving the organisation's ability to respond quickly to residents' information needs.

The final piece of the puzzle was helping GLA see what was happening inside their platform in real time. Tag1 worked with GLA and their vendor CIVIC to reconfigure New Relic, giving teams clearer insight into performance trends and regressions after each deployment. This visibility now shapes how GLA prepares for traffic peaks and ensures that slowdowns are caught early.

As Tag1 explained:

"While implementing New Relic, we used deployment markers to track metrics between code deployments. If a code change introduced a regression, the transaction metrics after the deployment marker would show the increase in load times."

They continued:

"New Relic also helps them understand how the site behaves under higher load. They have more visibility into which parts of their site are impacted more during high-traffic events. With regular Goose load testing before deploying to production, they can get in front of problems by simulating high traffic scenarios and identifying bottlenecks with New Relic's tracing features."

What emerges from these insights is a picture of a platform that didn't just get faster-it became predictable. With more than 50 improvements already implemented and another dozen queued for rollout, GLA has moved from reacting to performance problems to actively preventing them. Editors now work with fewer delays, residents experience consistently faster load times, and technical teams have the tools they need to detect issues before they ripple outward.

For a public institution responsible for communicating essential, time-sensitive information to millions, that shift is more than a technical upgrade. It is operational stability, delivered when it was most needed.

The collaboration between Tag1 and the Greater London Authority illustrates how focused performance work can reshape the reliability of a major public-facing platform. By removing long-standing bottlenecks, introducing consistent testing practices, and giving teams clearer visibility into site behaviour, Tag1 helped London.gov.uk operate with greater speed and stability at moments when residents depend on it most.

For GLA, these improvements mean faster publishing, fewer delays, and a system that responds predictably under pressure. And for agencies considering Drupal for large, multi-department websites, the project offers a grounded example of how thoughtful optimisation can extend the life and capability of an existing platform-strengthening performance without interrupting the work it supports every day.