Following up on the previous post
In my previous post, I talked about my deliberations and final decision to switch themes. Having made that decision, I immediately ran into a new question:
Switching the theme and enabling the CDN: in what order?
My original plan was to finish testing the “no CDN” data with the old theme, enable the CDN to get comparison results, and then switch the theme. This way, I would also have a record of the old theme’s “CDN speedup effect.” It seemed perfect.
But on closer thought, this plan has problems—and significant ones at that.
Why I rejected “enable CDN first, then switch theme”
First problem: the data cannot be compared
The most basic rule of performance testing is: change only one variable at a time.
If I enable the CDN first to gather data for the old theme, and then switch to the new theme, there will be two differences between the old and new data sets: “theme code” and “CDN status.” When the load speed changes are measured, will they be due to the CDN, or because the new theme itself is lighter or more bloated? It would be impossible to tell.
Moreover, data from the previous post already showed that 96% of my readers use Chrome, 93% use Windows, and over 35% have screen widths exceeding 1680px. The new theme will likely be better suited for these mainstream configurations, but this adaptation might also introduce more CSS and JS—these changes will all affect load times. If mixed with the CDN’s effects, they cannot be isolated at all.
Second problem: CDN caching would be a disaster
This is a more practical consideration.
CDN caching maps one-to-one based on URL paths. The old theme’s static file path is /wp-content/themes/hueman/, while the new theme’s is /wp-content/themes/newtheme/. If I enable the CDN first, the following will happen after switching themes:
- The old theme’s cached files will continue to occupy CDN node space until they expire and are released
- There will be no cache under the new theme’s paths, so all requests will pass through to the origin, causing an “origin pull storm”—effectively making the CDN useless
- If the old and new themes happen to have files with the same name (for example, both called
style.css), the CDN might mistakenly serve the old cache to visitors, causing page styling to break
This means that after switching themes, not only would I have to manually purge a large amount of cache, but I would also have to endure an awkward period of slower speeds during the initial rollout of the new theme. This completely defeats the original purpose of switching themes, as stated in the previous post—giving readers a better experience.
My choice: switch theme first, then enable CDN
Based on the above analysis, my operational steps are set as follows:
Step 1: Switch the theme
Choose a theme that is widescreen-friendly, fully responsive on mobile, and lightweight in code, then complete the migration and fine-tune the styles.
Step 2: Re-test the “no CDN” baseline
Use the same testing tools (PageSpeed Insights, Boorex, etc.) and nodes to re-run domestic and international network speed data, serving as the new theme’s “bare performance” scores.
There is a minor side note to this step: I had actually already finished testing the “no CDN” data for the old theme, but since I decided to switch themes, that data is now unusable—because changing the theme alters the page size and the number of requests. Comparing the old theme’s baseline against the CDN effects after switching themes would yield inaccurate conclusions. It’s a sunk cost, and I need to let it go.
Step 3: Enable the CDN
After the new theme runs stably for a few days, I will enable the CDN, let the cache naturally warm up with real visitor traffic, and then conduct a second round of testing to obtain pure CDN speedup data.
Step 4: Publish a comparison article
Compile the differences between the two sets of data and write an objective review of the CDN’s performance.
The benefits of this approach are:
- Controlling variables: Between the new theme’s “no CDN” and “with CDN” data sets, there is only one variable—whether the CDN is enabled—so the conclusions will be robust
- Avoiding caching issues: The CDN is not yet enabled when the new theme goes live, so there are no cache pollution or origin pull storm problems
- Smooth transition: After enabling the CDN, the cache builds up naturally with traffic, requiring no manual mass purging or warming
A point of reference for fellow tinkerers
Behind this seemingly simple choice of “enable CDN first or switch theme first” lies a dual consideration of the control variable principle and practical cache management. Although the old theme’s “no CDN” data was tested in vain, this sunk cost is worth paying compared to ending up with an unexplainable comparison result.
If you are also tinkering with a CDN or switching themes, my advice is simple:
- Make the decision first: will you switch themes? This decision shouldn’t be based on a gut feeling; go check the data.
- If you decide to switch, finish the switch before enabling the CDN. If the order is wrong, the subsequent troubles will be greater than expected.
I will later compile the selection process for the new theme and the actual CDN test data, so stay tuned.