Startups often face a dilemma: You want a global, fast application, but you also want the simplicity of a single serverless deployment. I built a product using Next.js and deployed it to Google Cloud Run. It was simple, scalable, and powerful.
But we had a problem. Speed. 🐢
🌏 The Challenge: The "Geography Tax"
Our Cloud Run instance was hosted in the us-central1 region. This is standard practice, but for our users in India, it meant every request had to travel halfway around the world and back.
- ❌High TTFB (Time To First Byte): 400ms - 800ms.
- ❌Cold Starts: If the container scaled down, the first user would wait 2-3 seconds for the server to wake up.
- ❌LCP (Largest Contentful Paint): ~9.6s on mobile.
We were failing the Core Web Vitals assessment. The app felt sluggish because the physics of standard HTTP requests were working against us.
🛠️ Phase 1: Code-Level Optimizations
We started by aggressively optimizing our application code to ensure we weren't the source of the slowness.
We implemented:
- Image Optimization: Converted our 600KB
hero.pngto a 127KBhero.webp. 🖼️ - Asset Shrinking: Crushed our SVG logo down to 1.8KB for mobile.
- Critical CSS Inlining: Enabled
experimental: { optimizeCss: true }in Next.js. 🎨 - Font Caching: tuned caching strategies for Google Fonts.
"Even with a tiny bundle, the browser still had to wait ~500ms just to receive the first byte of HTML from the US server. We realized that code optimization can only go so far when network latency is the bottleneck."
🚀 The Solution: Firebase Hosting
We decided to migrate to Firebase Hosting using their extensive Web Frameworks support for Next.js.
What is a CDN and Why Does It Matter? 🤔
To solve the "Geography Tax," you need a Content Delivery Network (CDN).
A CDN is a network of servers distributed globally to "Edge locations." Instead of every user fetching data from your single origin server (e.g., in the US), the CDN caches your content on servers physically closest to the user.
How it works
- Origin: Your main server (US) builds the site. 🏗️
- Propagation: The CDN copies your static assets (Images, CSS, JS) to hundreds of servers worldwide (Mumbai, London, Tokyo, etc.). 📡
- Delivery: When a user in India opens your site, they download the files from a server in Mumbai or Delhi, not the US. 🇮🇳
The Rendering Trio: SSG, CSR, and SSR
To truly understand why the migration helped, we need to look at how Next.js renders pages and how Firebase handles each type.
1. Static Site Generation (SSG) - The Speed Demon 🏎️
HTML is generated once at build time.
- Firebase Handling: Uploaded directly to global CDN.
- Our Use Case: Home Page & Landing Pages. TTFB dropped to 50ms.
2. Client-Side Rendering (CSR) - The Interactive Layer 👆
Browser fetches data on the fly.
- Firebase Handling: Skeleton HTML is cached on CDN.
- Our Use Case: Dashboards. Fast initial load.
3. Server-Side Rendering (SSR) - The Heavy Lifter 🏋️
HTML generated on-demand.
- Firebase Handling: Routed to Cloud Functions (2nd Gen). Slower TTFB.
- Our Use Case: Complex analysis reports.
The Migration Win: On Cloud Run, everything was effectively treated like SSR. By moving to Firebase, we unlocked the Global CDN for our static content.
⚙️ The Migration Process
The migration was remarkably simple using the Next.js integration.
{"hosting": {"source": ".","frameworksBackend": {"region": "us-central1"}}}
firebase experiments:enable webframeworks
firebase deploy
✅ The Result: 96/100
The impact was immediate and dramatic. Green lights across the board! 🟢
Conclusion
"Optimization isn't just about writing faster code—sometimes it's about moving that code closer to your users."
If you are building a Next.js app and deploying it as a standalone container, you might be missing out on the performance benefits of a specialized Edge network.
By moving to Firebase Hosting:
- ✔ We got a Global CDN out of the box.
- ✔ We properly utilized SSG for our critical landing pages.
- ✔ We significantly reduced Latency for our global users.