Introduction
A website returning HTTP 200 OK is often treated as the definition of “healthy.” Traditional uptime monitoring agrees—if the server responds successfully, the site is considered online.
Unfortunately, users don’t browse HTTP status codes.
This case involved a production WordPress website that remained online throughout the entire incident. No 500 errors. No database failures. No PHP fatal errors. Every uptime monitor reported success.
Yet visitors would occasionally receive pages that were visually unusable because large portions of the CSS were missing or incomplete.
Even more confusing, refreshing the page often made the problem disappear.
Those intermittent symptoms turned what initially looked like a CDN issue into a multi-day investigation involving Divi, Divi Pixel, Cloudflare APO, browser developer tools, visual monitoring, and several layers of caching.
This article documents a Divi CSS missing issue where WordPress pages occasionally loaded without CSS despite returning HTTP 200 OK.
Environment
The affected site was running the following stack:
| Component | Version / Service |
|---|---|
| CMS | WordPress |
| Theme | Divi 4 |
| Plugin | Divi Pixel |
| SEO | Rank Math |
| CDN | Cloudflare APO |
| Web Server | Apache |
| Monitoring | Checkly Playwright screenshot monitoring |
Several caching layers were active simultaneously:
- Browser cache
- Divi Static CSS
- Cloudflare APO
- Apache
- WordPress object/page caching where applicable
Individually, each layer is well understood. Together, they create a surprisingly complex content delivery pipeline.
Divi CSS Missing Symptoms
The production symptoms were inconsistent enough to make diagnosis difficult.
Visitors occasionally reported pages that looked like this:
Common observations included:
- HTTP status remained 200 OK
- Traditional uptime monitoring showed everything healthy
- Layout appeared partially unstyled
- Navigation sometimes shifted vertically
- Fonts occasionally fell back to browser defaults
- Refreshing the page often fixed the issue
- The problem might not reappear for hours
Browser Developer Tools occasionally showed errors such as:
GET https://example.com/wp-content/et-cache/...css 404
Failed to load resource: the server responded with a status of 404
Other sessions instead showed font-related failures:
Failed to load font
net::ERR_ABORTED
The inconsistency made it difficult to determine whether the failures were actually related or simply symptoms of another underlying issue.
Initial Theories
Rather than assuming a single cause, each reasonable possibility was investigated independently.
Cloudflare APO
Because Cloudflare APO aggressively caches fully rendered HTML, it was possible that Cloudflare had cached an incomplete page before all assets were available.
This became one of the strongest early theories.
Divi Static CSS
Divi generates Static CSS files that are rebuilt whenever settings change or caches are cleared.
If those files were unavailable—or regenerated incompletely—pages could render without styling.
Since missing CSS matched the observed symptoms, this was another leading suspect.
Browser Cache
Because refreshing frequently fixed the issue, browser caching seemed plausible.
Testing from multiple devices, browsers, and geographic locations eventually reduced confidence in this theory.
Plugin Conflicts
Multiple plugins modify frontend behavior:
- Divi
- Divi Pixel
- Rank Math
Any plugin that modifies rendering, optimization, or caching could potentially contribute.
Font Loading
Console logs occasionally referenced missing fonts.
Although missing fonts alone wouldn’t completely destroy page layouts, they suggested that frontend assets were sometimes unavailable.
Theme Issues
Since Divi performs significant frontend processing, a theme-level regression was also considered.
No evidence ultimately pointed toward a general Divi bug.
CDN Propagation
Cloudflare edge propagation occasionally causes inconsistent behavior immediately after cache changes.
Because users weren’t consistently hitting the same edge locations, CDN inconsistency remained a possibility throughout much of the investigation.
Investigation
Rather than chasing assumptions, each layer was tested independently.
Step 1: Browser Developer Tools
Chrome DevTools was the first stop.
The Network tab revealed occasional missing CSS resources.
The Console showed intermittent frontend errors.
Example:
GET /wp-content/et-cache/...css 404
Failed to load resource
No JavaScript exceptions explained the broken rendering.
Step 2: Compare Cloudflare vs Origin
Requests were compared directly against:
- Cloudflare
- Origin server
Using curl:
curl -I https://example.com/
curl -I https://origin.example.com/
Headers appeared normal:
HTTP/2 200
cf-cache-status: HIT
Nothing obvious suggested a backend failure.
Step 3: Search for PHP Errors
Server logs were inspected for:
- Fatal errors
- Database failures
- PHP warnings
- Theme exceptions
No significant errors coincided with the rendering failures.
Step 4: Resource Monitoring
Browser Network inspection focused on:
- CSS
- Fonts
- Images
- JavaScript
Only frontend assets occasionally failed.
The HTML itself remained valid.
Step 5: Visual Monitoring
This investigation changed dramatically after implementing screenshot monitoring with Checkly using Playwright.
Unlike traditional uptime checks, Playwright rendered the page exactly as a visitor would.
Example test:
import { test, expect } from "@playwright/test";
test("Homepage renders correctly", async ({ page }) => {
await page.goto("https://example.com", {
waitUntil: "networkidle",
});
await expect(page).toHaveScreenshot();
});
Instead of checking:
- HTTP status
- Response time
- SSL
the monitor captured an actual screenshot.
Several failures looked like this:
HTTP monitoring continued reporting:
200 OK
while screenshot comparisons clearly showed broken rendering.
This became the single most valuable diagnostic tool during the investigation.
Step 6: Observe Timing
Eventually a pattern emerged.
Failures clustered shortly after scheduled cache activity.
That observation shifted attention away from browsers and toward cache generation.
Root Cause
The eventual cause was not a server failure or Cloudflare outage.
Instead, the site was configured so that Divi Pixel automatically cleared Divi’s Static CSS cache once per day.
Under normal circumstances, Divi regenerated the required CSS without issue.
However, on this production site, the timing occasionally aligned such that:
- Divi Static CSS cache was cleared.
- Divi regenerated CSS assets.
- Cloudflare APO immediately cached the newly generated page.
- Some CSS assets were not yet consistently available across requests.
- Cloudflare then served that partially generated page until cache refresh.
The end result was a perfectly valid HTML page with incomplete styling.
Importantly, this was observed behavior on this specific production environment.
This investigation does not conclude that Divi Pixel contains a universal bug or that Cloudflare APO is inherently incompatible with Divi.
Instead, it demonstrates how independently functioning components can interact unexpectedly under certain timing conditions.
Resolution
The final remediation consisted of several simple changes.
Disable automatic Divi Static CSS cache clearing
Divi Pixel’s scheduled cache clearing was disabled.
Regenerate Static CSS manually
The Divi Static CSS cache was rebuilt once manually.
Divi
→ Theme Options
→ Builder
→ Advanced
→ Clear Static CSS File Cache
This allowed Divi to regenerate a complete, stable CSS set.
Allow Cloudflare APO to Cache the Stable Version
Once regeneration completed successfully, Cloudflare APO cached the stable pages normally.
No additional Cloudflare configuration changes were required.
Continue Visual Monitoring
Playwright screenshot monitoring remained enabled.
The monitor continued checking:
- Homepage
- Important landing pages
- Visual differences
- HTTP errors
- Browser console errors
- Failed resource requests
After disabling the scheduled cache clearing, the intermittent rendering issue did not reappear during continued monitoring.
Example Playwright Resource Monitoring
Visual screenshots are useful, but monitoring resource failures can provide additional context.
const failures = [];
page.on("response", (response) => {
if (response.status() >= 400) {
failures.push({
url: response.url(),
status: response.status(),
});
}
});
Capturing failed CSS requests alongside screenshots made correlating frontend failures much easier.
Lessons Learned
Several important lessons came from this investigation.
HTTP 200 does not mean a page is healthy
Servers can return perfectly valid HTML while users receive a completely broken experience.
Visual monitoring catches failures that uptime monitoring cannot
Screenshot comparisons immediately exposed problems that status-code monitoring missed entirely.
For modern websites, visual monitoring should be considered part of production health.
Multiple cache layers can interact in unexpected ways
Modern WordPress deployments frequently include:
- Theme caching
- Plugin caching
- Server caching
- CDN caching
- Browser caching
Each layer may function correctly in isolation while producing unexpected behavior together.
Scheduled maintenance tasks deserve scrutiny
Automatic cache clearing sounds harmless until another caching layer captures the site mid-regeneration.
Whenever scheduled optimization tasks are enabled, consider how they interact with upstream caches.
Browser Developer Tools remain indispensable
Despite increasingly sophisticated monitoring platforms, Chrome DevTools continues to provide invaluable visibility into:
- Failed resources
- Console errors
- Timing
- Network behavior
Those fundamentals solved this investigation.
Final Takeaway
This issue wasn’t caused by a single broken component.
Divi generated CSS correctly.
Cloudflare APO cached pages correctly.
Divi Pixel cleared caches exactly as configured.
The problem emerged from how those independent systems interacted during a narrow regeneration window.
The biggest lesson wasn’t about Divi or Cloudflare specifically—it was about observing the system as users experience it. Traditional uptime checks confidently reported a healthy site because they measured server availability, not visual correctness. Screenshot-based monitoring revealed the real problem almost immediately and transformed an intermittent, difficult-to-reproduce complaint into a measurable production issue.
When troubleshooting modern WordPress deployments, it’s worth considering every layer involved in serving a page: the application, theme, plugins, web server, CDN, browser, and monitoring strategy. Understanding how those layers work together is often more valuable than trying to identify a single component to blame.