Performance Issue: WP Offload Media (S3) is consuming high CPU usage when using

Posted in: Newspaper
Post count: 6

Hello TagDiv Support Team,

I hope this email finds you well.

I am experiencing a significant performance issue on my WordPress site, which uses the Newspaper/Newsmag theme and the TagDiv Composer plugin.

After noticing very high page load times on several pages on the site, I used the Code Profiler diagnostic tool to identify the cause. The results from the profiler indicated that the WP Offload Media plugin (formerly known as Leopard Offload Media), which I use to offload my media files to Amazon S3, is consuming an excessive amount of execution time (approximately 4 seconds) during page loads.

To diagnose the cause of this excessive consumption by WP Offload Media, I ran plugin isolation tests. I temporarily disabled other plugins to see which of them, when disabled, caused the execution time of WP Offload Media to decrease.

The tests clearly revealed that the high time consumption by WP Offload Media occurs only when the TagDiv Composer plugin is active.

I have attached the following screenshots from Code Profiler to illustrate this point:

Screenshots: https://imgur.com/a/TpPDo10

Screenshot 1 (With TagDiv Composer active): Shows the execution time of plugins with TagDiv Composer active. WP Offload Media appears at the top of the list with approximately 4 seconds of execution time.

Screenshot 2 (With TagDiv Composer disabled): Shows the execution time of plugins with TagDiv Composer disabled. The execution time of WP Offload Media drops dramatically to approximately 0.06-0.15 seconds, indicating normal behavior.

While disabling TagDiv Composer solves the performance issue with WP Offload Media, it is not a viable solution, since the layout of my pages (built with Composer) depends on it and breaks when disabled.

Based on these results, it seems that there is either a direct performance conflict or an inefficient interaction between TagDiv Composer and WP Offload Media that causes this excessive CPU consumption during page load when both are enabled.

I would like to know if you have any knowledge of this compatibility issue with media offload plugins for S3 (such as WP Offload Media) or if there is any specific setting within the Newspaper theme or TagDiv Composer that should be adjusted to mitigate this conflict and allow both plugins to work optimally together.

I would greatly appreciate your attention and any guidance or solution you can offer to resolve this crucial performance issue.

Thanks for your help!
Best regards,
André Sugai
andre@tutoriaisphotoshop.net
https://www.tutoriaisphotoshop.net

Post count: 7

I am experiencing a similar issue. I have reviewed all the queries using Query Monitor. In the past, I have encountered performance issues with this specific template.
I would appreciate it if, when assisting the original poster (OP), you could also provide a step-by-step guide that might help me resolve my issue as well.

Post count: 7

Mr andresugai, are you on the latest version of Newspaper?

Post count: 6

Hi, aminier86. Yes, i’m using Version: 12.7.1.

Post count: 7

Hello, I hope you’re doing well. If you’re feeling very frustrated while looking for a solution, you might consider downgrading to version 12.6.7 — this resolved the issue for me.

It is also advisable to clear any transient files on your database.

have a nice day!

Post count: 27744

Hello,

Please use the lazy load feature from the plugin: https://www.siteground.com/kb/lazy-loading/ and deactivate the one from Theme Panel → Template Settings (as shown here: https://i.imgur.com/kuMk2zO.png), because all the images are currently being loaded at once. After that, please check again.

Thank you!

Post count: 6

Hi Anamaria, how are you?
These are my settings, despite making the suggested changes the graph did not change and the loading time and CPU consumption remain high.

View post on imgur.com

Post count: 6

Hi aminier86, how are you?
I also tried to downgrade but it didn’t work. The hosting CPU consumption remained high and the page loading time was still compromised.

Post count: 7

Hello Andrés,

I recommend disabling the automatic backup option for theme configuration changes. You can find it under:
Theme Panel > Import and Export

Important Warning: Do not click on “Reset Theme Settings”, as it will restore all theme settings to their default values.

As a fellow user, I have found that disabling this feature significantly improves site performance. The reason is that this option stores a large configuration backup in the database, which the theme frequently queries, causing system overload and reduced performance.

Recommendation:
Manually save the configuration content in a .txt file regularly and completely disable the automatic backup feature.

View post on imgur.com

Post count: 6

Hi aminier86,

After disabling the backup option the loading time remains high. It doesn’t seem to have had an impact in my case :\

View post on imgur.com

Post count: 6

Update

After noticing a very high page load time on several pages on the site, I used the Code Profiler diagnostic tool to identify the plugins and themes that were contributing the most to the load time.

Initially, the profiler showed that the WP Offload Media plugin was consuming an excessive amount of time (approximately 4 seconds), which was the main factor in the slowness of the pages.

To diagnose the specific cause of this high consumption by WP Offload Media, I performed isolation tests of plugins and settings. I temporarily disabled other plugins and adjusted the WP Offload Media settings, running Code Profiler after each change.

The results of the isolation tests were very revealing:

Test 1 (Original Condition): With TagDiv Composer enabled and WP Offload Media enabled and configured to rewrite URLs to S3/CDN, WP Offload Media had an execution time of approximately 4 seconds. (See Screenshot 1: Original Condition)
Test 2: By disabling the TagDiv Composer plugin, the execution time of WP Offload Media dropped dramatically to around 0.06-0.15 seconds, a normal and acceptable time. (See Screenshot 2: TagDiv Composer Disabled)
Test 3 (Crucial Result): I kept TagDiv Composer enabled, but adjusted the WP Offload Media settings to disable URL rewriting (“Copy files also to Amazon S3” and “Rewrite Media URLs” options disabled). In this condition, with WP Offload Media still ON but not interacting with S3/CDN for rewriting, the execution time of WP Offload Media was approximately 0.22 seconds. (See Screenshot 3: WP Offload Media Active, S3/CDN Disabled, TagDiv Composer Active)
Based on these results, the conclusion is that the high CPU consumption and execution time by WP Offload Media (the 4 seconds) occurs specifically when the TagDiv Composer plugin is active AND WP Offload Media is configured to intercept and rewrite media URLs to Amazon S3/CDN. When S3 URL rewriting is disabled in WP Offload Media, even with the plugin active and TagDiv Composer active, the execution time of WP Offload Media returns to normal.
This strongly suggests that there is a conflict or inefficient interaction between WP Offload Media’s URL rewriting logic (when pointing to S3/CDN) and TagDiv Composer’s page processing. Unfortunately, disabling TagDiv Composer is not a viable solution, as it is critical to the structure and layout of my site built with your theme.

I was wondering if you have any knowledge of this specific compatibility issue or performance conflict when using TagDiv Composer/Newspaper Theme in conjunction with S3 media offload plugins that rewrite URLs (such as WP Offload Media). Is there a recommended setting within the theme or Composer, a specific plugin/theme version, or a workaround that can be applied to resolve this conflict and allow both plugins to work optimally together?

I greatly appreciate your attention, support, and any guidance you can provide in resolving this critical performance issue for my site.

Thanks for your help!

View post on imgur.com

Post count: 20685

Hi,

This situation is a bit unusual. If anything, the website should be much faster if the images are delivered from a fast external source. I’ve seen for example cases with the ewww image optimization plugin, which can deliver images from their CDN, and the performance was improved drastically. And I’ve seen other cases with other image CDNs being used, with great results. I’m referring to websites that were also using our theme.

Testing with the composer inactive isn’t that relevant, as the pages will just be a bunch of code with no or less images. The composer is the theme.

Using lazyload should help, there’s a difference from loading all the images at once, and just the ones that are actually in view. Right now I see no lazyload active on the website. And I see that at this time the images are not served externally anymore on the website.

The problem could be with the source of the images, or something related to the offload plugin. What if its something similar to this topic https://wordpress.org/support/topic/wp-offload-media-lite-causing-huge-number-of-db-queries/ Are all the images offloaded? Or if you check with the query monitor plugin, is there also a high number of queries from the plugin?

Thank you!

Viewing 12 posts - 1 through 12 (of 12 total)
You must be logged in to reply to this topic.