devops & infrastructure

How a “Simple Blank Page” in a React App Exposed a CDN + IIS Failure Pattern We Didn’t Expect and How We Fixed It

Umesh Gajjar
February 11, 2026
4 min read
56 views
A seemingly random blank page in a production React application exposed a deeper infrastructure failure between CloudFront and IIS. What appeared to be a frontend issue was actually a CDN caching problem triggered during IIS restarts, where HTML responses were mistakenly cached for JavaScript assets. Here’s how we diagnosed the failure pattern and redesigned the system for resilience instead of relying on cache invalidation.

Hook (Intro)


We assumed a blank page meant a frontend bug.
We assumed clearing cache would fix it.
We assumed CDN + IIS was a solved problem.

All three assumptions were wrong.

What looked like a random, non-reproducible UI issue turned into a multi-layer production failure that only surfaced under very specific timing conditions — and only for some users.

The Context

We were running a production-grade React SPA behind AWS CloudFront, served from a Windows IIS origin.

Stack:

  • React (production build with hashed assets)

  • Node.js backend APIs

  • IIS serving static build + reverse proxy

  • AWS CloudFront as CDN

  • Enterprise gateway layer (WebSEAL / proxy)

    • The application was business-critical.
    Stability mattered more than pixel perfection.


    What Most Guides Recommend

    Typical advice says:

  • Configure CloudFront TTL properly

  • Invalidate cache after deployment

  • Ensure IIS rewrite rules are correct

  • Add React error boundaries

  • Ask users to clear browser cache

    • We followed most of it.

    Everything looked correct on paper.

    What Actually Happened in Production

    Users intermittently reported:

  • A completely blank screen

  • Console error:

    • Failed to load module script… server responded with MIME type text/html
  • Refresh sometimes fixed it

  • Cache clear sometimes fixed it

  • Sometimes it remained broken for specific users only

    • Important signals:

  • Could not reliably reproduce it

  • More frequent after IIS restarts or patching

  • Not all users affected

  • Sometimes appeared hours after a restart

    • This wasn’t a typical frontend bug.


    The Real Root Cause

    The issue wasn’t React.
    It wasn’t CloudFront alone.
    It was the interaction between them.

    The Broken Assumption

    We assumed:

    If IIS restarts and comes back up, everything is fine.

    In reality:

  • During app pool recycle or brief restart, IIS occasionally returned HTML fallback pages for asset requests

  • CloudFront cached that response

  • A JavaScript request received HTML once

  • That response became “valid” at CDN/browser level

  • React attempted to execute HTML as JS → hard crash → blank screen

    • The system behaved correctly.
    It just wasn’t resilient.


    What We Changed

    We stopped trying to “fix cache” and instead made the system resilient.

    IIS Changes

  • Updated rewrite rules to exclude static assets

  • Prevented .js and .css from being rewritten to index.html

  • Enforced correct MIME types

  • Returned proper 404 for missing assets

  • Applied no-store headers for HTML responses

    • CloudFront Changes

  • Configured custom error responses (403, 404, 502, 503, 504)

  • Set error caching TTL to 0

  • Prevented caching of temporary failures

    • Frontend Changes

  • Added startup-level JS load failure detection

  • Implemented one-time safe reload

  • Added React Error Boundary

  • Introduced structured error logging with shared Error ID

  • Replaced blank screen with controlled error page

    • No hacks.
    No aggressive invalidations.
    No forced browser cache clearing.


    The Result

    After implementation:

  • Blank page incidents stopped

  • MIME mismatch errors disappeared

  • IIS restarts no longer poisoned CDN cache

  • Users now see controlled error screens instead of blank UI

  • Error IDs allow traceable debugging

    • Performance remained stable.
    CDN still cached valid content.

    Failures became visible — not silent.


    When This Approach Works Well

    This pattern fits when:

  • You run a React SPA behind a CDN

  • Your origin server may restart periodically

  • You cannot reliably reproduce production-only issues

  • Stability is more important than aggressive caching

    • Especially useful in enterprise multi-layer environments.


    When You Should NOT Do This

    Avoid this pattern if:

  • You rely on long-lived HTML caching

  • You cannot modify IIS rewrite rules

  • Your app is fully static and doesn’t execute runtime JS

  • You lack logging infrastructure

    • This is resilience engineering — not a universal template.


    Key Takeaways

  • Blank pages are often infrastructure problems, not UI bugs

  • CDNs cache responses, not intent

  • IIS fallback behavior can silently break SPAs

  • Resilience matters more than perfect cache tuning

  • Visible failures are better than silent crashes


    • FAQ

    Why didn’t cache invalidation solve it?

    Because the issue wasn’t stale content — it was incorrect content cached as valid.

    Why not just increase CloudFront TTL?

    TTL does not fix incorrect responses. It can amplify them.

    Could monitoring have detected this earlier?

    Partially. The issue was timing-based and user-specific, making detection inconsistent.

    ---

    Closing Thoughts

    Random blank pages are rarely random.
    They live in the interaction between systems — not inside a single one.

    If you’ve chased something similar in production, I’d be interested in how you approached it.

    reactcloudfrontiiscdnspa deploymentproduction buginfrastructuredevops
    0 comments

    Comments (0)

    No comments yet. Be the first to share your thoughts!

    Let's Collaborate

    Ready to Put These Skills to Work?

    Let's discuss how my technical expertise can help bring your vision to life and drive your business forward.

    Get in TouchView Projects