Hi there, Sebastian here, I hope you are doing well!
I understand your checkout page has been displaying incorrectly, with unstyled text, broken image layouts, and barebones forms, and that you’ve traced the issue to Jetpack Boost. I can see how frustrating this must be, especially on such a critical page for your shop. Let’s work on getting Boost running smoothly for you again.
The good news is that you likely don’t need to give up Jetpack Boost entirely. The issue is almost certainly caused by one or two specific Boost features conflicting with how the Blocksy theme loads its CSS, not by the plugin as a whole. From this Blocksy guide: Blocksy uses a dynamic, on-demand CSS loading system, which means it only loads the styles needed for each page. Some optimization features can interfere with this approach.
To find the culprit, here’s what I’d recommend:
- Re-enable Jetpack Boost, then go to Jetpack > Boost in your dashboard and disable all the optimization toggles first.
- Turn features back on one at a time, checking your checkout page after each one. The most likely culprits are:
- Concatenate JS and CSS – This has a known history of breaking WooCommerce checkout blocks. I’d test this one first.
- Optimize CSS Loading (Critical CSS) – This may not correctly capture all the styles Blocksy needs for the checkout page.
- Defer Non-Essential JavaScript – This could defer scripts that are actually required for checkout forms and payment processing.
- You can also quickly test by adding these query parameters to your checkout page URL:
yoursite.com/checkout/?jb-disable-modules=critical_cssyoursite.com/checkout/?jb-disable-modules=minify_css,minify_jsyoursite.com/checkout/?jb-disable-modules=render_blocking_js If the page loads correctly with any of these, you’ve found the problematic feature.
- Once you identify which feature causes the issue, keep it disabled and use the other Boost features normally. You’ll still benefit from the remaining optimizations (Page Cache, Image CDN, and the other features that don’t conflict).
Regarding APCu and Jetpack Boost: you’re right that they do different jobs. APCu is an object cache that stores WordPress/PHP data in memory to reduce repeated processing and database work, while Jetpack Boost’s page cache stores cached page output for visitors. They usually don’t conflict directly because they operate at different layers. However, if Jetpack Boost has cached a broken version of the checkout page, it may keep serving that version until the cache is cleared. After changing Boost settings, clear Jetpack Boost’s page cache from Jetpack → Boost → Cache Site Pages, and if your host provides APCu object caching, clear that cache from the hosting control panel as well.
For more detailed guidance, here are some helpful resources:
Also, could you share your site URL? That would allow me to take a closer look and run some diagnostics on my end to pinpoint the exact issue faster.
Looking forward to hearing how the testing goes!
Warm regards,
Thanks Sebastian.
We forgot to mention that previous to write the first post we wiped all caches in an attempt to solve it, but didnt work.
Anyways, after testing one by one, it turned out Concatenate CSS was the one messing things up, weird that it was working good until now but whatever.
The site is fairydragronprints.com if you are still wanting to run tests. You migth find more errors and things not properly set up, we are sure of it. We dont know much about web and everytime we had an issue like 90% of the results when looking for a solution has been ‘buy my services’ or ‘pay this suscription/plugin’, so every problem was solved via test and error of whatever goes on our mind and sticking with the one that do not break everything. So if you look into it and have any suggestion we are extremly happy to hear.
And again, thanks a lot for helping us out solving the checkout page issue
Hi there, Sebastian here!
I am glad you were able to narrow it down to Concatenate CSS, and I have to say, great job troubleshooting this on your own! Identifying the exact feature causing the issue is no small task, so well done.
That is actually a known behavior with the Blocksy theme. Blocksy uses an on-demand CSS loading system, meaning it only loads the styles each page needs. When Concatenate CSS combines all those files into one, it breaks that system and can cause exactly the kind of styling issues you experienced on checkout. Blocksy’s own documentation actually recommends against combining CSS files for this reason: The case of over-optimising your website.
So keeping Concatenate CSS disabled is absolutely the right call for your setup. The good news is that Blocksy’s on-demand loading already does a great job keeping things lightweight, so you are not losing much by leaving that one off. All the other Boost features (Page Cache, Image CDN, Defer Non-Essential JavaScript, Optimize CSS Loading, Concatenate JS) should continue working well alongside it.
I ran a quick diagnostic on your site, and while most things look good, I did notice an intermittent issue worth addressing. Jetpack needs this connection to work for most of its features. We are seeing the following error: the REST API request with the blog token is timing out with a cURL error 28. This means your server is sometimes too slow to respond to Jetpack’s requests, which can affect some Jetpack features over time. This is typically caused by the hosting provider limiting concurrent PHP connections. Here is what I would recommend:
- Contact your hosting provider and ask them to
- Once your host confirms the changes, reconnect Jetpack by following this guide. Don’t worry, your stats and followers will remain intact.
Please let us once this is done and we can check the connection again.
Warm regards,
Ok according to our host provider they have done the suggested changes. They told us the server is not blocking incoming/outgoing connections over XML-RPC, and added the ips to the whitelist.
Fom our side we just completed the recconect Jetpack step.
So it should be solved now, tell us how it goes when you do another check
Thanks
Hi @namelessnk –
Thanks for making those changes. We still are having trouble with the error:
http_request_failed: cURL error 28: Operation timed out after 5002 milliseconds with 0 bytes received
Do you have any plugins that restrict access to the REST API? For example, security plugins?
If not, I’d recommend reaching out to your host and asking them to check the load on your server. It may be that your server is responding to slowly to our requests.
This is an example of a failing request:
https://www.fairydragonprints.com/xmlrpc.php?for=jetpack&token=Ow2wXin%24Yii%24ahxe1Ok4gbZmibs6n4F8%3A1%3A0×tamp=1773327829&nonce=4Keqzs0cOh&body-hash=YpK8wg675VHNMMeuAm1muupdBq8%3D&signature=3xBR4RS%2Bn1hbLBu4IJ3jfWTK5XI%3D
To our knowledge we are not using anything that restricts REST API, how could we check that?
Hi @namelessnk,
The easiest way to check is to go to Plugins > Installed Plugins in your dashboard and look for any security plugins like Wordfence, Sucuri, iThemes Security, or anything with “security” or “firewall” in the name. These sometimes block REST API or XML-RPC access without you realizing it.
Since the timeout is still happening after your host made changes, it’s also worth asking them to check their server logs for any clues around the time of the failure.
Thanks!
We dont have plugins with “security” nor “firewall” in the name, neither any of the listed.
The closest to security related plugins we have are plugins for error log and debugging like decalog and querry monitor.
We passed your request to our host and this was their response:
“””
We have checked the server access and error logs. The access log shows requests to xmlrpc.php are reaching the server and returning a successful response, for example:
POST //xmlrpc.php HTTP/1.0 200
This confirms the server is processing the requests normally and is not blocking Jetpack connections.
Based on our checks, the server is responding normally. The cURL error 28 usually indicates a timeout caused by the website application (such as plugins or theme).
“””
So…. it is the theme? Any other ideas? Should we check every plugin we have?
Hello @namelessnk
Thanks for ruling out those security plugins and checking with your host.
So we took another look at the debug data and found your site is running behind Cloudflare.
Here’s our guide for getting Cloudflare and Jetpack playing nicely together. Could you work through the steps in there? https://jetpack.com/support/getting-started-with-jetpack/configure-jetpack-cloudflare/.
If you’re not sure where it’s set up, please check with your host as it might be deployed at the host level.
Once you have configured Cloudflare to allow Jetpack traffic as shown above, go ahead and fully deactivate, delete, and reinstall Jetpack fresh — that’ll give the connection a clean slate. Your settings are stored on our end so nothing will be lost. You can follow our guide here for this step: https://jetpack.com/support/reconnecting-reinstalling-jetpack/.
Let us know how it goes!
Ok, we set up a new custom rule in cloudflare for the ASN of Jetpack according to the provided guide, and made a reinstallation of jetpack.
Let me know if it’s fixed or we missed something.
Thanks for all
Hi @namelessnk,
Thanks for confirming all that, I took another look from our side as well.
What I’m seeing now is that the requests are reaching your site (we do get a 200 OK), but the response is either taking too long or not returning everything Jetpack expects. That’s why we’re still seeing the timeout (cURL error 28) and the missing method in the XML-RPC response.
So this doesn’t look like a full block anymore, but more like something in between affecting how the request is handled.
The most helpful next step here would be a quick isolation test: could you temporarily disable the Cloudflare proxy and let me know once that’s done?
This helps us confirm right away if Cloudflare is introducing delay or altering the response. If things start working after that, we’ll know exactly where to focus next. If not, we can continue narrowing it down from there.
Thanks again for sticking with this, we’re getting closer.
Ok, it’s done, we paused the cloudflare service, to our knowledge is off
Hi there!
Thanks for pausing Cloudflare.
Good news: XML-RPC appears to be now passing on all fronts. The remaining issue is that your server’s REST API connection fails when authenticating with the blog token — this is the channel WordPress.com uses to communicate back to your site.
While investigating, we noticed your server may be caching responses and serving stale ones back, which would cause token validation to fail.
Here’s what we’d recommend:
- Purge all server-side caches .
- Reinstall and reconnect Jetpack once the above is done — follow this guide for that.
If the issue persists after that, it’s also worth asking your host to allowlist Jetpack’s IP addresses and ensure the /jetpack/v4/ and /wpcom/v2/ REST API namespaces aren’t being blocked by any security rules.
Once you have finished the above steps, you can check the Jetpack connection status for your site here. It should shown a message that says Everything looks great!.
Let us know how it goes!
The host side changes where already done previously by instruction of one collegue of yours.
Prior to repeat again the cache purge and reinstal of jetpack, we just went to the url you provided to do the test, and right now it shows the Everything looks great! so we guess it has been solved already?
Hi @namelessnk,
Great to hear the debugger is showing “Everything looks great!” now.
The changes you and your host made (Cloudflare configuration + IP allowlisting) seem to have resolved the main connection issues.
While we’re still seeing a small delay on one of our deeper checks, this shouldn’t affect how Jetpack works day to day.
Just to double-check, are all the Jetpack features you’re using working as expected now? If you notice anything off, let me know here and we can take another look together.
