This usually happens because of several reasons, such as a lot of background processing, the database is too slow or there are external API calls made.
It’s uncertain what causes this, but it depends entirely on the context of the website, where it’s hosted and what’s loaded inside. It could be a faulty plugin, or a slow query (or multiple queries) and so on.
Here’s a couple of things you can try to debug this:
Follow this article https://support.reytheme.com/kb/debugging-problems/ to enable WP_DEBUG constant, and make sure to check if there are php errors generated.
Install the Query Monitor plugin to get reports of the number of queries, duration and overall DB performance, as well as memory consumtion.
After installing you should see the reports in the top Admin bar ex: https://d.pr/i/ljABBK .
For a quick comparison, here’s a screenshot of London’s demo Query Monitor overview https://d.pr/i/XizEDC .
The basic principle is avoiding a large number of queries. In that screenshot, there’s around 480 queries given that this page loads a large header with a lot of features, WooCommerce product grids, and other various elements that may need to query the DB.
Most plugins have some form of sending information to their respective API server to get the latest version information, in some cases telemetry data, and so on.
When you see a slow load, make sure to check the HTTP API tab in Query Monitor eg: https://d.pr/i/4ruLbv . There might be a slow request, a bad request etc.
There were many cases in various sites where these types of request could take tens of seconds even minutes (depending on server timeout configuration). So make sure to verify it.
- Remove overhead and clean up transients.
- Archive old data. There are plugins available that can help you archive old data so they don’t clog up your primary tables.
A sizable database can slow down query performance.
Given that the issue may come from a specific or multiple plugins, try disabling plugins one by one (and refresh in the meantime) to see if there are improvements.
I recommend keeping active only Query Monitor, WooCommerce, Elementor and Rey Core, and gradually activate the other plugins one by one until you can spot the one(s) that could add a bigger payload.
You can try disabling Rey Core plugin too, but please know that this plugin acts as a pipeline in many situations and a lot of content passes through it (eg: main content, product grids elements, Global sections – Header, Footer, etc.) and while disabling it will obviously show a decrease in consumptions and queries, but only because this content is not rendered anymore.
A WordPress caching plugin aims to improve website performance and reduce load times by storing static files and serving them to subsequent visitors. Here’s how it generally works:
- Object Caching: Object caching involves storing database queries so that when a page is rendered, fewer calls to the database are needed. This can improve the speed of dynamic sites where database queries can be a bottleneck.
- GZIP Compression: Many caching plugins offer the ability to compress files, making them smaller and faster to download, thereby speeding up website access times.
- Lazy Loading: Some caching plugins also offer lazy loading, where images and other media files are only loaded when they are about to be displayed on-screen, which speeds up initial page loading times.
- CDN Integration: Many caching plugins support integration with Content Delivery Networks (CDN). A CDN can distribute the load, save the bandwidth, and speed up access for your global visitors.
- Preloading: Preloading involves generating the cache for all pages in advance so that users don’t have to wait for the cache to be built when visiting a page for the first time.
- Cache Expiry and Garbage Collection: The plugin often provides settings to determine how often the cache should be cleared and regenerated. This is especially important for sites with dynamic content.
- Mobile-specific Caching: Some plugins offer caching solutions specifically optimized for mobile users.
Popular WordPress Caching Plugins:
- WP Super Cache
- LiteSpeed (for LiteSpeed servers)
- WP Optimize
- WP Fastest Cache
- WP Rocket (premium)
By definition, Redis and Memcached are both in-memory data storage systems. Memcached is a high-performance distributed memory cache service, and Redis is an open-source key-value store.
It’s probably best to ask your hosting support team if any of them is supported on your server.
On each image upload, WordPress is generating resized variants of that image, based on preset sizes which are registered by WordPress itself (thumbnail, medium, large), WooCommerce (thumbnail, main gallery, gallery thumbs etc.) and even Rey (blog image, 16/9 sized image).
This process can be very expensive, especially on shared servers and especially if the images are very large and there are many pre-set sizes.
That’s why i recommend disabling some of these sizes with this plugin https://wordpress.org/plugins/image-sizes/. In fact, at least for the moment, i only recommend having the Large, Medium and Thumbnail enabled. If it affects the frontend in some way, you can enable other sizes later on and use this plugin https://wordpress.org/plugins/regenerate-thumbnails/ to regenerate the images on those missing sizes.
To learn more about this please visit this article How to Prevent WordPress from Generating Image Sizes .
Basically Ajax requests are uncached by default so there’s real scripting and processing inside them. If more code runs in the background, it can affect their performance and duration.
To see the exact timing of an Ajax request, you can use the Inspector tool ex: https://d.pr/v/oxb0ZU .
Many Ajax requests are native to WooCommerce, so they contain a lot of hooks other plugins can hook into and run their code. So even if i ensure everything runs fine in Rey and no code “leak”, other plugins might do it.
The best way to debug the Ajax requests is to disable plugins one by one and measure the timing pile up. Start with only Elementor & WooCommerce enabled and then activate the other plugins one by one. It’s a somewhat measurable way of figuring out if some plugin might create a bottleneck.