Website styling broken after enabling Azure Front Door caching

Question

Website styling broken after enabling Azure Front Door caching

Abdelrhman Goma 135

Problem Description

We implemented Azure Front Door caching for our Next.js website hosted on Azure Container Apps to reduce costs, but the site styling is broken. Pages load without CSS initially, then flash to correct styling after a delay.

Current Setup

Front Door Profile: Standard tier

Origin: Azure Container Apps (Next.js application)

Route: /* with caching ENABLED

Rule Sets: 3 rules in this order:

What We've Verified

✅ HTML is NOT being cached (x-cache: CONFIG_NOCACHE)

✅ JS files ARE being cached (TCP_MISS → TCP_HIT)

✅ CSS files show proper cache headers from origin (max-age=31536000)

✅ Static assets are being cached after first request

The Issue

Despite correct caching behavior, the website:

Takes longer to load than before

Shows unstyled content initially

Then "pops" into correct styling after a delay

Sometimes styles are completely missing on first visit

Questions

Is there a specific order required for rules with Next.js applications?

Do we need to handle /_next/static/* paths differently?

Could there be a conflict between Front Door caching and Next.js automatic static optimization?

Is there a recommended caching strategy for Next.js apps on Container Apps?

How can we debug what's causing the delay between HTML load and CSS application? User's image

Praveen Bandaru 10,900 Reputation points Microsoft External Staff Moderator

2026-03-19T18:42:03.2333333+00:00
Hello Abdelrhman Goma

And after adding the ruleset please try to do purge operation on the front door level and test it.

Check the front door access logs and verify the TimeTaken,TimetoFirstByte,Cache Status,RouteName,MatchedRulesSetName,OriginName / OriginIP / OriginURL and a TrackingReference that matches the X-Azure-Ref header. If the latency or bites miss from the origin it was expected behavior only.

Check the below document:

https://learn.microsoft.com/en-us/azure/frontdoor/monitor-front-door?pivots=front-door-standard-premium

https://learn.microsoft.com/en-us/troubleshoot/azure/front-door/troubleshoot-performance-issues

For further investigation, please try to collect the HAR file during the time the issue occurs and share it with me via private message. I have already initiated a private message, so please check and send the file to me.

After enabling Azure Front Door caching for the Next.js application on Azure Container Apps, we noticed that while static assets like JavaScript and CSS are cached, the site initially loads without styling, followed by a short delay before styles appear. This happens because the HTML response loads faster than the CSS assets, and since HTML is not cached, it is fetched directly from the origin each time. On first visits or during backend cold starts, CSS files may take longer to load, causing the temporary unstyled appearance.

For optimal configuration, static asset paths (such as /_next/static/*) should be handled separately from dynamic routes. It’s best to cache only immutable static assets on dedicated routes, leaving dynamic content uncached. Mixing static and dynamic paths under one rule can cause delays or conflicts during initial rendering.

We are reviewing the Front Door rules and their order of execution. Since rules are processed sequentially, general rules placed before static asset-specific rules can impact how CSS and JavaScript files are cached or routed. Prioritizing static asset rules can help prevent this issue.

Next, we suggest updating Azure Front Door routing so static assets are managed with dedicated, cache-enabled routes, while the main application route remains uncached. We are also assessing backend performance and Container App scaling settings to reduce cold start delays that may contribute to the problem.

Check the document for more understanding:

https://learn.microsoft.com/en-us/azure/frontdoor/front-door-caching?pivots=front-door-standard-premium

I hope the above answer helps you! Please let us know if you have any further questions.

Please don't forget to "upvote" where the information provided will help you, this can be beneficial to other members of the community.
Praveen Bandaru 10,900 Reputation points Microsoft External Staff Moderator

2026-03-20T19:26:51.0366667+00:00

Hello Abdelrhman Goma

I just wanted to follow up and see if you had a chance to review my answer to your question. Please let us know if you found it useful, and don't hesitate to contact us if you have any further questions.

I hope the above answer helps you! Please let us know if you have any further questions.

Please don't forget to "upvote" where the information provided will help you, this can be beneficial to other members of the community.

Answer accepted by question author

1 additional answer

Your answer

Praveen Bandaru 10,900 Reputation points Microsoft External Staff Moderator

2026-03-20T19:26:51.0366667+00:00

Hello Abdelrhman Goma

I just wanted to follow up and see if you had a chance to review my answer to your question. Please let us know if you found it useful, and don't hesitate to contact us if you have any further questions.

I hope the above answer helps you! Please let us know if you have any further questions.

Please don't forget to "upvote" where the information provided will help you, this can be beneficial to other members of the community.

Answer 1

Hello **Abdelrhman Goma
**When accessing the front door domain, you are receiving partial content with 206 status code. Please check how the backend is responding. If you receive a 206 status code, it may indicate that the backend is compressing data, especially if compression is enabled at the backend level.

Also, verify whether compression is enabled on both your backend and at the front door level. If compression is enabled on both sides, this behavior is expected.

You should disable compression on either the backend or the front door. Additionally, cache also disabled on this scenarios.

If you continue to experience issues after disabling compression, it could be due to a large backend file size and enabled compression on the backend.

In such cases, implement a rule set to disable compression and accept encoding headers as shown in the screenshot.
User's image

If this rule doesn't work, you'll need to address the issue from your backend to reduce the size of the custom ranger headers.

I hope the above answer helps you! Please let us know if you have any further questions.

Please don't forget to "accept the answer" and "upvote" where the information provided will help you, this can be beneficial to other members of the community.

Tariq Ghouri 40 Reputation points

2026-03-25T14:26:38.4933333+00:00

Worked with me .
Abdelrhman Goma 135 Reputation points

2026-03-26T10:09:06.51+00:00

HI Praveen Bandaru
Thanks a lot For your support Now everything is working appreciate it .

Answer 2

Azure Front Door caching and rules do not have any Next.js‑specific ordering requirements in the documentation. The key guidance is to:

Cache only static assets (CSS, JS, images, fonts, etc.).
Avoid caching dynamic or user‑specific content (HTML pages, authenticated APIs).
Validate behavior with browser dev tools and the x-cache header.

From the context:

Only GET requests are cacheable; other methods are always forwarded to origin.
Static assets such as images, CSS, and JavaScript files are ideal for caching.
Dynamic assets such as authenticated API endpoints should not be cached.
It is recommended to have separate routes for static and dynamic assets, with caching disabled for the latter.
For Power Pages, a working pattern is:
- One route with caching enabled.
- A rule set that:
  - Caches only specific static extensions (.css, .png, .jpg, .js, .svg, .woff, .ico) with an overridden cache duration (for example, 7 days).
  - Leaves page HTML uncached (x-cache: CONFIG_NOCACHE).
- Validation via browser dev tools to ensure:
  - Static files show x-cache without NOCACHE.
  - Page requests show x-cache: CONFIG_NOCACHE.

Applied to the described setup:

Route configuration
- Keep a single route like /* with Caching enabled.
- Use Use Query String or Ignore Query String depending on whether query parameters affect static asset content.
- Ensure HTTPS only and compression enabled as desired.
Rule set strategy
- Rule 1 (dynamic paths like /api, /auth, /login, etc.):
  - Condition: request path contains those segments.
  - Action: caching enabled at route level is fine, but rule should effectively result in no caching for these paths (for example, by honoring origin headers that set no-store/no-cache).
- Rule 2: cache Next.js static assets
  - Condition: request path begins with /_next/static/.
  - Action: caching enabled, compression enabled, cache behavior override with a suitable TTL (for example, 7 days or longer if assets are content‑hashed).
- Rule 3: cache other static assets
  - Condition: request path ends with static extensions such as .js, .css, .jpg, .png, .svg, .webp, .ico, .woff.
  - Action: caching enabled, compression enabled, cache behavior override with desired TTL.
This mirrors the documented pattern where static files are cached and page content is not.
Handling /_next/static/*

The context explicitly recommends using routing rules to separate static and dynamic content and cache static content at the edge. Using a rule that matches /_next/static/ and caches those assets is aligned with this guidance.

Debugging the delay between HTML and CSS

The documentation recommends validating caching behavior with browser developer tools:

Open dev tools before loading the page.
On the Network tab:
- Confirm that CSS and JS requests show x-cache without NOCACHE (indicating they are cacheable and can be served from edge).
- Confirm that page HTML requests show x-cache: CONFIG_NOCACHE.
If x-cache for CSS or JS shows CONFIG_NOCACHE, the rule set is not matching as intended and those assets are not being cached at the edge, which can cause slower styling application.

Recommended caching strategy for this scenario

Based on the documented best practices:

Keep HTML and authenticated API responses uncached.
Cache all static assets (including /_next/static/* and other static file extensions) with a reasonable TTL.
Use rule sets to:
- Match static assets by path or extension and enable caching with overridden TTL.
- Ensure dynamic routes are not cached.
Validate with dev tools and x-cache headers after each rule change, noting that rule changes can take up to 10 minutes to propagate.

This approach aligns with the documented pattern for Power Pages and the general Azure Front Door caching guidance and should avoid styling flashes caused by uncached or inconsistently cached CSS/JS.

References:

Share via

Website styling broken after enabling Azure Front Door caching

1 additional answer

Your answer