Next.js and ISR Transform Quran.com’s Frontend, Scaling to 50 Million Monthly Users
How Next.js and ISR helped Quran.com scale to tens of millions of users with edge caching, code-splitting, and CDN strategies that cut TTFB and bundle size.
Rebuilding a High-Traffic Frontend with Next.js and ISR
When Quran.com faced severe load and slow first paints across its global audience, the frontend team led a migration from a client-side single-page React application to Next.js with Incremental Static Regeneration (ISR). That shift—centered on pre-rendering pages and revalidating them on a schedule—became the core performance and scalability strategy that enabled the site to reliably serve tens of millions of users monthly. ISR, implemented with conservative revalidation for largely static content, and a layered CDN approach were the levers that delivered large reductions in time to first byte and dramatic improvements in cache efficiency.
Why the Single-Page App Approach Was Failing
Quran.com originally served its pages as a client-side rendered SPA. Under that model, every page load required server execution and client-side rendering before users saw meaningful content, producing a uniform slow first paint for all visitors. With heavy traffic concentrated in regions such as Asia and the Middle East, that model created a fragile critical path and scaling pressure on origin infrastructure. The team concluded that a different rendering strategy was required to get pre-rendered HTML into users’ hands quickly and reduce origin load.
How Next.js and Incremental Static Regeneration (ISR) Were Applied
The migration placed Next.js at the center of the frontend stack and used ISR to pre-render pages at build time while allowing background revalidation on a schedule. For content that changes infrequently—Surah pages, for example—the team set ISR revalidation to 3,600 seconds (one hour). This meant most page requests could be served from pre-rendered HTML rather than invoking server rendering on each request.
By treating ISR as a scalability mechanism rather than a mere performance optimization, the team reduced the server-side critical path across high-traffic regions. The reported outcome was a drop in time to first byte (TTFB) of more than 70% for users in Asia and the Middle East, where the site’s traffic is heaviest.
Edge Caching as a Second Layer: Cloudflare in Front of Vercel
ISR alone was not the complete solution. The project added a second layer of caching by placing Cloudflare in front of the Vercel deployment, instructing the CDN to cache ISR-generated pages at the edge. That configuration ensured users in cities such as Riyadh, Karachi, and Jakarta received responses from geographically proximate nodes rather than waiting for origin responses.
A key part of the CDN strategy was the use of a stale-while-revalidate pattern in cache-control headers. The team configured page responses with a header instructing the CDN to serve cached content immediately and revalidate the content in the background. The cache-control value used by the team included public, s-maxage=3600, stale-while-revalidate=86400, allowing one-hour freshness for shared caches and permitting edge nodes to serve stale content while fetching updates.
That combination of ISR and an aggressively tuned CDN policy produced a large improvement in cache efficiency: the CDN cache hit rate rose from roughly 40% to about 92%.
Code Splitting and Bundle Optimization to Reduce Client Load
Serving tens of millions of users also required shrinking client-side payloads. The team performed an audit of dependencies and implemented aggressive code-splitting tactics to keep initial JavaScript small and targeted:
- Heavy client components such as the audio player and the translation viewer were loaded via dynamic imports to avoid inflating the initial bundle.
- Route-based splitting leveraged Next.js dynamic routing so only route-relevant code was delivered on first load.
- User preferences (theme and language settings) were moved to client-side state to avoid generating personalized HTML that would bust caches for otherwise identical pages.
These measures reduced the initial JavaScript bundle size by about 45%, improving client performance and reducing bandwidth pressure across the site’s global audience.
Operational Details That Supported Stability
Beyond rendering and caching changes, the project standardized runtime choices and libraries used across the frontend. The stack adopted Next.js 14 with the App Router and ISR, deployed on Vercel with Cloudflare as a CDN layer, and used React Query together with Zustand for state management. The codebase was written in TypeScript throughout. Those decisions created a consistent, typed code surface and a predictable runtime that made it easier to apply broad optimizations such as cache-control policies and targeted code-splitting.
Why These Architectural Choices Matter at Scale
Working at 50 million monthly users reframes performance decisions: what can look like premature optimization on a small site becomes essential at high scale. ISR was presented not as a superficial performance trick but as a principled scalability strategy. Small gains in the critical path compound across millions of requests—an illustrative point in the project noted that shaving 100 milliseconds off TTFB translates into faster loads for millions of users per day, with downstream effects on engagement and return visits.
For content-heavy Next.js applications, the team’s experience demonstrates that early attention to pre-rendering strategies and edge caching can prevent costly retrofits later. Implementing ISR and edge caching from the outset helps preserve cache-friendly HTML, reduces origin pressure, and simplifies subsequent optimizations.
Developer Practices and Tooling Choices
The project’s approach highlights several practical developer-focused decisions:
- Treat static and rarely changing pages as primary candidates for ISR and edge caching rather than forcing personalization into pre-rendered output.
- Use dynamic imports to defer heavy, interactive features so they do not inflate the critical path for first paint.
- Keep personalization in client-side state when possible to avoid cache fragmentation and frequent cache invalidation.
- Apply conservative revalidation windows for content that changes rarely; one-hour revalidation for Surah pages was the team’s chosen cadence.
These practices intersect with common developer tooling and platform choices: bundler configuration and code-splitting strategies, state management libraries, CDN configuration, and deployment platforms. Aligning these layers reduces friction when applying cache policies and measuring their effects in production.
Business and User Experience Implications
The architectural changes deliver both operational and experiential benefits. From an operational standpoint, pre-rendering plus edge caching reduces origin compute and bandwidth, making traffic spikes easier to absorb and lowering the cost of serving high volumes of requests. From a user experience perspective, faster time to first byte and smaller initial bundles mean quicker first paints and less waiting for interactive features, which can increase engagement for returning users and make discovery for new visitors smoother.
The project’s reported metrics illustrate these dual benefits: a >70% drop in TTFB for traffic-heavy regions and an increase in CDN cache hit rate from ~40% to 92%, combined with a ~45% reduction in initial JavaScript payloads. Those gains show how frontend engineering choices map to measurable improvements in both infrastructure load and perceived performance.
Applying These Lessons to Other Projects
For teams building content-first applications on Next.js, the Quran.com case provides a reproducible pattern:
- Identify pages that are stable enough for ISR and set revalidation windows appropriate to the content’s update cadence.
- Put a high-performance CDN in front of the deployment and align cache-control headers with your revalidation strategy—allowing
stale-while-revalidatebehavior at the edge can keep user latency low while ensuring freshness is maintained. - Audit third-party dependencies and apply route- and component-level splitting to trim the initial execution payload.
- Keep personalization out of server-rendered HTML where possible to preserve cacheability and reduce cache churn.
Adopting these steps early can prevent a future migration under the pressure of growth, freeing engineering teams to focus on features rather than firefighting scalability problems.
The Stack at a Glance
The frontend stack used for the migration and scaling effort included:
- Framework: Next.js 14 with the App Router and ISR
- CDN: Cloudflare
- Deployment: Vercel
- State management: React Query and Zustand
- Language: TypeScript across the codebase
These choices supported predictable builds, typed code safety, and runtime characteristics that made cache and bundle optimizations straightforward to implement.
Operational Metrics and the Importance of Measurement
Key metrics reported by the team—TTFB reduction, CDN cache hit rate, and initial bundle size—guided prioritization and validated the architecture changes. Tracking cache-hit ratios and client bundle sizes before and after major changes made it possible to quantify the return on engineering effort and to calibrate revalidation windows and cache headers against real traffic patterns.
How This Work Shapes Frontend Engineering Practices
The Quran.com migration underscores a broader shift in frontend engineering: as traffic scales, the focus moves from single-request performance tweaks to systemic architectural patterns that preserve cacheability and push computation away from the origin. Techniques like ISR, strategically configured CDN caching, and disciplined client bundle management are becoming foundational practices for high-traffic content sites built with modern frameworks.
For developers working in adjacent ecosystems—developer tools, observability platforms, and automation frameworks—this pattern highlights opportunities to provide better primitives around ISR workflows, automated cache-policy validation, and package-level insights that reveal client-side payload cost.
If you want to discuss the migration or the engineering choices in more detail, the author of the frontend work is available for conversation and maintains a presence at zunain.com.
As traffic patterns and edge infrastructure continue to evolve, expect to see greater emphasis on hybrid rendering models and tighter integration between hosting platforms and CDNs; teams that treat pre-rendering and edge caching as architectural first-order concerns will be best positioned to deliver both fast and resilient user experiences at web scale.
