Achieving 95+ Lighthouse: Edge Caching & Bundle Optimization

In the fast-evolving domain of web development, the pursuit of instantaneous user experiences and stellar search engine optimization (SEO) scores is relentless. Even with advanced architectures leveraging global edge networks, unforeseen performance bottlenecks can emerge. This was precisely the challenge faced by ScribeToAny, an innovative full-stack audio and video transcription platform. Built on the modern React 19 framework and deployed to Cloudflare Workers, its heavy GPU-intensive tasks like Whisper transcription, diarization, and translation were efficiently offloaded to asynchronous platforms. Yet, despite this sophisticated backend, the frontend performance initially lagged, revealing a crucial gap in its otherwise advanced infrastructure.

Initial real-world user monitoring, specifically through Cloudflare Observatory, painted a concerning picture: the 75th-percentile Time To First Byte (TTFB) stretched to an alarming 3,128 milliseconds, with over half of all user interactions rated as "poor." Direct curl tests against cold edge nodes consistently showed TTFB values between 3.4 and 3.6 seconds for critical pages like the homepage and various SEO tools. This stark reality contradicted Cloudflare's internal Worker metrics, which indicated a median CPU wall time of a mere 5 milliseconds. The paradox was clear: how could a serverless function that completed its computational work in milliseconds take several seconds to deliver a response to the user's browser? This discrepancy highlighted a common yet often overlooked challenge in modern edge deployments, necessitating a deep look closely at the underlying architecture to diagnose and resolve the performance chasm.

The Performance Paradox: Unmasking the Cold Start Conundrum

The perplexing gap between the reported 5ms CPU execution time and the multi-second TTFB was the first major hurdle in optimizing ScribeToAny. Cloudflare Worker CPU metrics, while useful, only capture the active execution time of the handler function. They do not account for critical preceding steps essential for a serverless environment to function. These steps include the crucial time spent on isolate creation, the downloading of the worker's bundled JavaScript code, and the subsequent V8 JavaScript engine script compilation. This invisible overhead was the silent culprit behind the extended TTFB.

Upon closer inspection of the deployment pipeline, two primary factors converged to create this significant cold-start bottleneck. Firstly, the worker bundle size was substantial, clocking in at approximately 11MB. ScribeToAny, being a comprehensive platform, incorporated a rich array of SEO tool routes, including over 80 distinct audio and video conversion and transcription utilities, alongside solid markdown renderers and various format converter functionalities. All these features contributed to a large, monolithic JavaScript payload that had to be loaded and compiled by the V8 engine on every cold start. Secondly, the application's baseline traffic density was relatively low, averaging around 0.1 requests per second. This sparse traffic meant that Cloudflare's edge Points of Presence (PoPs) frequently evicted idle V8 isolates to conserve resources. Consequently, almost every new visitor, particularly those arriving from organic search results, was greeted by a brand-new, uninitialized cold isolate. Before the actual 5ms server-side rendering (SSR) handler could even begin its work, the V8 engine was forced to load and compile an 11MB JavaScript bundle from scratch. This process alone imposed a punishing 3-second penalty on the first visit, severely undermining the user experience and negatively impacting the site's potential SEO rankings, as search engines increasingly prioritize page speed.

Building on this, initial Lighthouse audits revealed significant Total Blocking Time (TBT) on mobile devices. This was attributed to heavy JavaScript execution during the hydration phase, where third-party authentication scripts and excessively large vendor chunks monopolized the main thread, delaying interactivity. Addressing these multifaceted performance issues required a systematic, layered optimization strategy that targeted both server-side cold starts and client-side rendering inefficiencies.

Strategic Edge HTML Caching for Instantaneous Delivery

A fundamental realization in addressing ScribeToAny's performance woes was that Cloudflare Workers do not inherently cache dynamic Server-Side Rendered (SSR) responses. This meant that every incoming HTTP GET request, even for static content, was hitting the Worker, invariably triggering the costly cold-start compilation process described earlier. To circumvent this, a crucial first step was to implement robust edge-level HTML caching directly within the Worker's `src/server.ts` file, leveraging the powerful Workers Cache API, specifically `caches.default`.

This implementation was designed with meticulous attention to detail to ensure both performance gains and data integrity. The core idea was to serve pre-rendered HTML from the nearest Cloudflare edge PoP for anonymous, public-facing pages, completely bypassing the Worker's execution for repeat visits or even initial visits if the content was recently cached. Even so, implementing caching for dynamic web applications demands strict safety boundaries to prevent serving stale or personalized content inappropriately.

The caching strategy incorporated several critical rules:

Session Isolation: To maintain user privacy and ensure personalized experiences, any incoming request containing a `better-auth.session_token` cookie would completely bypass the cache. This guaranteed that logged-in users always received fresh, dynamically rendered SSR content tailored to their session, preventing the accidental caching of sensitive user-specific data.
Strict Allowlist for Paths: Caching was rigorously restricted to a predefined allowlist of anonymous public pages. This included the homepage (`/`), pricing pages (`/pricing`), about us (`/about`), changelog (`/changelog`), all SEO tools (`/tools/*`), blog posts (`/blog/*`), and various legal pages. Conversely, dynamic routes such as user dashboards (`/dashboard`), API endpoints (`/api/*`), and settings pages (`/settings`) were explicitly excluded from caching, as their content is inherently dynamic and user-specific.
Conditional Cache Writing: HTML responses were only stored in the cache if they met specific criteria. This included having an HTTP status code of `200` (indicating a successful response), a `Content-Type` header of `text/html`, and crucially, the absence of a `Set-Cookie` header. The `Set-Cookie` header typically signifies a personalized response or session management, which should not be cached for general public consumption.

This intelligent caching mechanism ensured that for eligible requests, the system would first check `caches.default`. If a cache hit occurred, the response would be served almost instantaneously, marked with an `X-Edge-Cache: HIT` header, effectively eliminating the cold-start penalty for a significant portion of traffic. This foundational layer dramatically improved the TTFB for public pages, setting the stage for further optimizations.

Ensuring Freshness: The Build-Time Cache Invalidation Strategy

While edge HTML caching provided a monumental leap in performance, a significant challenge with Cloudflare Workers' `caches.default` API is its default behavior: a new Worker deployment does not automatically purge existing cache entries. This means that if a standard URL-based cache key is used, publishing a new blog post, updating marketing content, or deploying a critical bug fix could result in users being served stale HTML for days, depending on the cache's Time To Live (TTL). This problem can severely degrade user experience and undermine the agility of content updates and bug fixes.

To overcome this critical "stale content" problem, ScribeToAny implemented an ingenious build-time invalidation strategy. The core idea was to inject a unique, compile-time build identifier directly into the cache key. This identifier effectively creates a new, distinct cache key for every single deployment, rendering old cache entries immediately unreachable and ensuring that new content is served without delay.

The implementation involved two key steps:

Injecting a Build ID during Compilation: Using the Vite build tool (though similar approaches exist for Webpack or other bundlers), a unique identifier was injected into the build process. In `vite.config.ts`, the `define` option was used to create a global constant, `__EDGE_BUILD_ID__`, set to a stringified timestamp (e.g., `Date.now().toString(36)`). This ensures that every new build, by its very nature, generates a different `__EDGE_BUILD_ID__`.
Constructing a Versioned Cache Key: Within `src/server.ts`, the `edgeCacheKey` function was modified to incorporate this `__EDGE_BUILD_ID__`. For cacheable requests, a new URL was constructed where `__EDGE_BUILD_ID__` was appended as an internal query parameter (e.g., `__ev=abcdef`). It's crucial to note that this query parameter is purely internal; it is only passed to `cache.match` and `cache.put` and is never exposed to the client browser or passed upstream to the origin server.

With this mechanism in place, whenever a new version of the Worker is deployed, the `__EDGE_BUILD_ID__` changes. This immediately invalidates all previous cache entries, as the system now looks for keys tagged with the new build ID. Old cache entries are then left to expire naturally based on their configured TTL, while the new release begins populating the cache with fresh content immediately. This innovative approach allowed ScribeToAny to safely set aggressive cache durations, such as `s-maxage=86400` (24 hours) and `stale-while-revalidate=604800` (7 days), without any concern about serving stale HTML after a release. The outcome was phenomenal: edge cache hits now consistently returned in under 45 milliseconds directly from the nearest Cloudflare edge PoP, completely bypassing the Worker isolate cold starts and delivering an unparalleled level of responsiveness to anonymous users.

Optimizing Client-Side Bundles for Enhanced Interactivity

While delivering HTML quickly from the edge was a critical first step, the battle for superior web performance was far from over. The browser still had to parse and execute a significant amount of JavaScript before the page became fully interactive. If this client-side processing was unoptimized, the user experience would still feel sluggish, negating many of the gains made on the server side. ScribeToAny's initial client-side setup suffered from a common issue: an oversized JavaScript bundle.

The site's configuration, located in `src/config/website.ts`, originally bundled a vast array of metadata, navigation structures, and other global settings. This approach, while convenient during initial development, led to a monolithic JavaScript bundle that had to be downloaded, parsed, and executed by the browser even for pages that didn't require all of its contents. This contributed significantly to the Total Blocking Time (TBT), especially on less powerful mobile devices, which was a major factor in the site's initial poor Lighthouse scores.

To address this, a systematic approach to main bundle decoupling and vendor splitting was implemented. The core idea was to break down the large JavaScript payload into smaller, more manageable chunks that could be loaded on demand or in parallel, thereby reducing the initial download size and execution time. This involved:

Decoupling Global Configurations: The large `src/config/website.ts` file, containing extensive metadata and navigation data, was refactored. Instead of being bundled into the main JavaScript, parts of it were either fetched asynchronously when needed or pruned to include only what was absolutely essential for the initial page load. This meant that components or pages that didn't require the full breadth of the site's configuration wouldn't be burdened by its payload.
Aggressive Vendor Splitting: Modern build tools like Vite (or Webpack) offer advanced capabilities for code splitting. ScribeToAny harnessd these features to separate third-party libraries (vendors) from the application's core logic. Libraries such as React, `@tanstack/react-query`, and various UI component libraries were moved into their own distinct bundles. This allowed browsers to cache these vendor chunks independently. If a user visited multiple pages, the vendor code would likely already be cached, reducing subsequent load times.
Dynamic Imports and Lazy Loading: For less critical components or features that weren't immediately visible or essential for initial interactivity, dynamic imports were utilized. This technique allows JavaScript modules to be loaded on demand, only when they are actually needed (e.g., when a user clicks a button, scrolls to a specific section, or navigates to a particular route). This significantly reduced the initial JavaScript payload that the browser had to process, leading to a much faster time to interactive (TTI).

By implementing these strategies, ScribeToAny drastically reduced the size of its main JavaScript bundle, which in turn lowered the initial parsing and execution time. This had a direct positive impact on mobile Lighthouse scores, particularly improving metrics related to TBT and Time to Interactive, making the application feel much snappier and responsive to user input.

Beyond Initial Load: Refining Hydration and Third-Party Script Performance

Achieving a fast initial HTML delivery and reducing JavaScript bundle sizes were crucial, but the optimization journey extended further into the realm of client-side interactivity and the efficient management of third-party scripts. Even with a smaller main bundle, an inefficient hydration process or poorly managed external scripts could still monopolize the browser's main thread, leading to perceived lag and a frustrating user experience, especially on mobile devices. The Lighthouse audits had specifically flagged heavy Total Blocking Time (TBT) during hydration, indicating that the application was unresponsive for a significant duration after the initial content appeared.

ScribeToAny tackled this by focusing on several key areas:

Optimized Hydration Strategy: React 19 brought enhancements to hydration, but the application's implementation needed fine-tuning. This involved ensuring that only the absolutely necessary components were hydrated initially and that this process was prioritized. Techniques like partial hydration or progressive hydration (where parts of the application become interactive incrementally) were considered and applied where appropriate. The goal was to minimize the amount of JavaScript executed on the main thread during the critical initial rendering phase, allowing users to interact with the page much sooner.
Efficient Third-Party Script Loading: Third-party scripts, such as those for authentication, analytics, or advertising, are notorious for their potential to block the main thread and degrade performance. ScribeToAny systematically audited its third-party script usage. For non-critical scripts, strategies like `defer` and `async` attributes were employed to prevent render-blocking. Critical authentication scripts, which were essential but heavy, were carefully analyzed to ensure they loaded as efficiently as possible, perhaps through strategic lazy loading or by integrating them more tightly with the application's own code splitting mechanisms. The aim was to ensure these scripts did not delay the primary content from becoming interactive.
Resource Prioritization and Preloading: Modern browsers offer mechanisms to hint at resource priorities. For critical JavaScript bundles or CSS files, `<link rel="preload">` or `<link rel="preconnect">` were utilized to inform the browser to fetch these resources earlier in the rendering process, reducing the overall critical rendering path. This ensured that once the HTML arrived, the necessary assets for interactivity were already being downloaded or were readily available.
Image Optimization: While not explicitly detailed in the original source, a comprehensive performance strategy typically includes image optimization. Ensuring images are served in modern formats (WebP, AVIF), are properly sized, and lazy-loaded (using `loading="lazy"`) for off-screen content further reduces page weight and improves perceived load times.

By meticulously refining the client-side experience, particularly through optimized hydration and intelligent third-party script management, ScribeToAny ensured that the gains from edge HTML caching weren't undermined by a sluggish frontend. The result was a smoother, more responsive user interface that truly reflected the speed and efficiency of its underlying edge infrastructure.

A Holistic Victory: From Cold Starts to Peak Performance

The journey to optimize ScribeToAny's web performance was a testament to the power of a systematic and multi-layered approach to web development. What began as a puzzling discrepancy between internal CPU metrics and real-world user experience evolved into a comprehensive strategy that addressed every facet of performance, from the server-side edge to the client-side browser. The initial challenge of 3.5-second cold starts, driven by an oversized Worker bundle and low traffic density, was a clear indicator that even the most advanced serverless architectures require careful tuning and an understanding of their operational nuances.

By implementing an intelligent edge HTML caching layer, ScribeToAny effectively bypassed the costly V8 isolate compilation for anonymous users, slashing TTFB to milliseconds. The innovative build-time cache invalidation mechanism ensured that this aggressive caching never led to stale content, providing both speed and content freshness. Further, the meticulous decoupling of the main JavaScript bundle and strategic vendor splitting significantly reduced the client-side payload, leading to faster parsing, execution, and a dramatic improvement in Total Blocking Time (TBT) and overall interactivity. Finally, by refining hydration processes and optimizing the loading of third-party scripts, the perceived performance and responsiveness of the application were elevated to match its backend efficiency.

The cumulative effect of these optimizations was transformative: ScribeToAny not only eliminated its debilitating cold-start penalties but also achieved a remarkable 95+ Lighthouse performance score. This holistic victory underscores that true web performance is not about isolated tweaks but a continuous commitment to engineering excellence across the entire stack. It demonstrates that with the right diagnostic tools and a deep understanding of modern web technologies, even complex applications can deliver lightning-fast experiences that delight users and satisfy the stringent demands of search engine algorithms.

What This Means for Developers

The journey of ScribeToAny offers profound lessons for web development agencies, independent developers, and project teams, especially those working with modern serverless and edge computing platforms. For the Voronkin Studio team, this case study reinforces our core philosophy: performance is not an afterthought; it's a fundamental feature that directly impacts business outcomes. When clients approach us with complex web applications, particularly SaaS platforms, e-commerce sites, or content-heavy portals, we immediately consider their deployment environment. The ScribeToAny scenario highlights that even with cutting-edge technologies like Cloudflare Workers, the devil is in the details of implementation. Agencies must move beyond simply deploying to the edge and deeply understand the runtime characteristics of these environments, including V8 isolate lifecycle, bundle compilation, and cache management. This means performing comprehensive performance audits early in the project lifecycle, not just at the end, to identify potential cold-start issues, excessive bundle sizes, and hydration bottlenecks before they become critical.

For a web agency like Voronkin Studio, applying these lessons to client projects involves a multi-pronged strategy. Firstly, we advocate for a "performance budget" from the outset, setting clear targets for metrics like TTFB, TBT, and LCP (Largest Contentful Paint). Secondly, our development process incorporates continuous performance monitoring, integrating tools like Lighthouse CI into our build pipelines to catch regressions. Architecturally, we prioritize intelligent caching strategies, extending beyond CDN-level caching to application-specific edge caching with robust invalidation mechanisms, much like the build-time ID approach. For complex applications, we meticulously analyze JavaScript bundle composition, leveraging advanced code-splitting techniques and dynamic imports to ensure only necessary code is shipped to the client, thereby minimizing the critical rendering path. This often involves a detailed review of third-party script dependencies and their impact on main thread blocking, opting for lazy loading or deferral where possible.

Concrete steps for developers and project teams include: first, thoroughly understanding your deployment environment's specific performance characteristics—if you're on a serverless platform, investigate isolate cold start behavior and bundle size limits. Second, invest in automated performance tooling; Lighthouse, WebPageTest, and RUM (Real User Monitoring) solutions are non-negotiable for identifying real-world bottlenecks. Third, adopt a proactive approach to bundle optimization, treating your JavaScript and CSS payloads as critical assets that must be as lean as possible. This involves aggressive code splitting, tree-shaking, and careful management of vendor dependencies. Fourth, implement intelligent caching strategies, not just for static assets, but for dynamic HTML responses where appropriate, and crucially, design a robust cache invalidation mechanism to prevent stale content. Finally, prioritize client-side hydration and main thread responsiveness; a fast-loading page is useless if it's unresponsive to user interaction. These practices are not mere optimizations; they are foundational pillars of modern web development that deliver tangible business value through superior user experience and improved SEO.