Georgi Ganchev

Hello @alessiorealini,

We thank you for the report! This is the first time this issue has been reported, and we have brought it to the attention of our developers.

At this point, the reported issue has a score that marks it as low priority and not an impactful threat. This indicates that the problem may not pose any direct risk to your website’s security, and thus no actions are deemed absolutely necessary. You can continue using the plugin, and there is no need to deactivate it on your applications.

We will provide you with an update as soon as we hear from our developers.

Best regards,
SiteGround.com

Have a wonderful weekend @karenmansoldo!

Hello @louisesouter,

If you’ve already cleared the Dynamic caching from the Speed Optimizer plugin and the changes still aren’t visible on your live site, the issue might be due to caching by another plugin or the theme itself. In this case, additional cache clearing or asset cleanup might be necessary. I recommend checking if there is another plugin that applies caching to the homepage and clearing its cache to ensure your updates are reflected.

Additionally, if your theme includes specific settings for the footer, make sure the changes are applied there as well. Some themes have custom settings that can override the default WordPress footer settings.

Should you need additional help on our end, do not hesitate to contact SiteGround Helpdesk.

Best regards,
Georgi Ganchev
SiteGround.com

Hello @patboran ,

This issue often arises from dynamically generated CSS/JS files that trigger the re-creation of the CSS/JS combination file with each request. To resolve this, it’s important to identify the files causing the problem and exclude them from the CSS/JS combination feature in our plugin. You can use the following filters to exclude specific files:

add_filter( 'sgo_css_combine_exclude', 'css_combine_exclude' );
function css_combine_exclude( $exclude_list ) {
  // Add the style handle to the exclude list.
  $exclude_list[] = 'style-handle';
  $exclude_list[] = 'style-handle-2';

  return $exclude_list;
}

add_filter( 'sgo_javascript_combine_exclude', 'js_combine_exclude' );
function js_combine_exclude( $exclude_list ) {
  $exclude_list[] = 'script-handle';
  $exclude_list[] = 'script-handle-2';

  return $exclude_list;
}

For more details on using custom filters, please visit: SiteGround Custom Filters Tutorial.

Additionally, there is a cron event named siteground_optimizer_check_assets_dir that should automatically clear the siteground-optimizer-assets folder once a day if it exceeds 1000MB. You may want to verify that this event is scheduled correctly.

Typically, the contents of the /public_html/wp-content/uploads/siteground-optimizer-assets/ folder should be automatically cleared when you purge the SG cache from the admin area of the application, which helps reduce the folder’s size.

If the issue persists, I recommend submitting a Helpdesk request through your SiteGround account. Our technical team can then review the case, investigate further, and provide more detailed information.

Best regards,
Georgi Ganchev
SiteGround.com

Hello @dtrim ,

Inspecting your website from Chrome browser I can see that most of the images are opening with the .webp format. Keep in mind that .png above 1 mb are not converted to .webp. In addition to have the images converted they must be uploaded by standard way through the WordPress media gallery.

On your Home page there is just one image that remains as jpeg type and it might not be uploaded with default method as it appears related to your theme: themes/clifton-audiology/img/hearing-test.jpg, the rest are resolved as .webp

Best regards,
Georgi Ganchev

Hello @antoniospecchia ,

Thank you for taking the time to provide your feedback on our plugin. We truly value the insights from our users as they help us improve and enhance our product.

Our team of experts is dedicated to creating a seamless experience for all users, and we apologize if the plugin wasn’t as intuitive as we intended. We understand that clear instructions and usability are crucial, and we appreciate your perspective on this matter.

We would love to learn more about the specific challenges you encountered so we can address them effectively. Please feel free to reach out to us directly with any details or suggestions you might have. Your input is invaluable in helping us make our plugin better for everyone.

Thank you again for your feedback and for helping us improve.

Best regards,
Georgi Ganchev
SiteGround.com

Hello @enviousdigital,

Please open a Helpdesk request through your Client Area so we can inspect the error and check the server logs to see if there is something related that could be causing this.

The error might be related to a conflict with another plugin or .htaccess rules restricting the work of the REST API as well.

Best regards,
Georgi Ganchev
SiteGround.com

Hello @quixtar ,

Thank you for reaching out and providing the URL for inspection. Upon reviewing it, I noticed that there are several custom cookie settings in place that modify the default caching mechanism. It’s important to note that the plugin adheres to all cookie policies, which is why certain pages, like WooCommerce product pages, are not cached. In the example you’ve shared, there’s a cookie that restricts caching to just 1 hour.

wordpress_lp_guest=acba4ffd7370e9a6357632a79ad4be19:

Expires: Tue, 01-Apr-2025 06:23:21 GMT
Max-Age: 3600 seconds (1 hour)
Path: /

It seems these settings are enforced by the LearnPress plugin. I would recommend checking its configuration to see what adjustments can be made in this regard.

Furthermore, since the cookie modifies caching, the page is identified as dynamic content. Here’s what the output from curling the URL indicates:

Caching Information:

• sg-f-cache: BYPASS: This shows that the server-side caching mechanism is bypassed for this request, meaning the content is generated dynamically rather than served from cache.
• x-cache-enabled: True: This suggests that while caching is enabled on the server, it is bypassed in this particular instance.
• x-proxy-cache: MISS: This indicates that the request did not retrieve data from a cache, and the content was fetched directly from the origin server.
• x-proxy-cache-info: 0 NC:000000 UP:SKIP_CACHE_SET_COOKIE: This provides detailed cache status information. The SKIP_CACHE_SET_COOKIE part suggests that caching was skipped due to the presence of Set-Cookie headers, which typically indicate dynamic content that should not be cached.

I regret to inform you that there is no specific filtering available to prevent automatic cache purges. The plugin monitors WordPress hooks and will purge the entire page cache or perform a partial purge when certain events trigger it.

If you have any more questions or need further assistance, please feel free to reach out.

Best regards,
Georgi Ganchev
SiteGround.com