Troubleshooting common issues with Optimize LCP Images within Jetpack Boost

Posted on June 18, 2025 by Liam Sarsfield

If Jetpack Boost isn’t optimizing your Largest Contentful Paint (LCP) images as expected, this guide can help you identify common issues and resolve them.

Pages not being optimized

Check page availability

  • Ensure your important pages are publicly available, and not password protected.
  • Verify pages return 2XX HTTP response (not 404 or server errors).

Review page structure

  • Pages with one clear, prominent visual element work best.
  • Multiple competing large images can complicate LCP detection.
  • Very complex layouts may require manual optimization.

Optimization results not visible

Clear caches

  • Clear your site’s page cache.
  • Clear CDN cache if applicable.
  • Test in a private/incognito browser window.

Verify implementation

On a Cornerstone Page, view the page source and look for the following attributes:

  • fetchpriority="high" on optimized images.
  • loading="eager" instead of lazy loading.
  • data-jp-lcp-optimized="true"

Specific error types

HttpError

Cause:

The page failed to fully load within 60 seconds — often due to slow server response or large, complex pages.

Solution:

  • Check your hosting performance and server logs.
  • Make sure the page loads quickly and reliably.
  • Try testing with a lighter version of the page.

LcpTimeout

Cause:

Jetpack Boost couldn’t reach the page due to a network or HTTP error — usually caused by timeouts, firewalls, or unstable connections.

Solution:

  • Verify the page loads consistently and returns a valid response (2XX HTTP code).
  • Ensure your hosting provider allows external services like Jetpack to access your site.
  • Temporarily disable security or firewall rules that may block Jetpack.

LcpMetricTimeoutError

Cause:

Jetpack Boost loaded the page successfully, but couldn’t detect the Largest Contentful Paint element within 60 seconds.
This can be caused by pages with slow-loading content, or dynamic content that never stabilizes.

Solution:

  • Ensure the page has visual content that loads within a reasonable timeframe.
  • Check for JavaScript errors or infinite loading states that prevent content from stabilizing.
  • Verify the page isn’t primarily empty, redirect-heavy, or composed entirely of dynamically-loaded content.

ElementNotUnique

Cause:

Jetpack Boost detected multiple large visual elements and couldn’t determine which one should be optimized as the LCP.

Solution:

  • Simplify your layout or ensure there’s one clearly dominant visual near the top of the page.
  • Avoid having multiple competing hero images or background sections above the fold.

ElementNotStable

Cause:

Jetpack Boost identified a potential Largest Contentful Paint element, but it did not remain consistently visible for several seconds during analysis. This often occurs with carousels/auto‑rotating sliders, animated hero sections, or components that quickly swap, fade, or slide content after load.

Solution:

  • Keep the hero/LCP element visible for at least 3 seconds during initial load (e.g., pause or delay autoplay/rotation).
  • Set the slider to start on the hero slide and delay the first transition (≥ 3s).
  • Minimize heavy entrance animations that immediately replace the hero content.
  • If you cannot make these changes yourself (e.g., using a theme or slider plugin without settings):
    • Contact the theme/slider plugin authors and request that their carousel respects prefers-reduced-motion: reduce (pause/disable autoplay and transitions when users prefer reduced motion).
    • Ask for a setting to disable or delay autoplay on initial load so the main slide remains visible long enough for analysis.

Unknown

Cause:

Jetpack Boost was unable to determine the cause of the issue during analysis.

Solution:

  • Wait a few minutes and try again.

Still Need Help?

Please contact support. We’re happy to advise.

Comments Off on Troubleshooting common issues with Optimize LCP Images within Jetpack Boost

Jetpack Boost Cornerstone Pages

Posted on November 15, 2024 by Liam Sarsfield

Improve your site’s speed by optimizing its most important pages with the Cornerstone Pages setting.

Cornerstone pages are specific pages on your website that Jetpack Boost prioritizes. It applies tailored optimizations to improve these pages’ performance rather than making broad changes across the entire site.

Number of allowed pages

This setting is available on both the Boost free plan and the Boost Premium plan: the free plan allows you to optimize your homepage and one additional page, while the Premium plan supports your homepage and up to ten pages additional pages.

Read more about Jetpack Boost plans.

Cornerstone Pages usage

The Cornerstone Pages setting is automatically enabled once you activate Boost. You can find it below the Page Speed scores section, right above all of Boost’s features.

The box including all the Cornerstone Pages information is collapsed by default, and it shows the number of pages you currently have set up.

Clicking the arrow pointing down will expand the section, giving you more details about the preferences, including a way to manage the list of pages.

First time running Boost and Default Pages

When you activate Boost (or click Include default pages), it will populate the Cornerstone Pages list with the following URLs:

The list is limited to the number of pages available in your Boost plan.

Homepage

The home page is always a cornerstone page. For that reason, it’s above the list in its own section.

This means that you do not need to add it to the list. If you try and do that, you will be greeted with an error message.

Edit the list of pages

When adding new URLs in Cornerstone Pages, you can enter a full URL (https://example.com/shop/) or a relative URL (/shop/).

If you provide a relative URL (/shop/), Boost will expand that for you to a full URL – https://example.com/shop/

Jetpack Boost stores relative URLs for the Cornerstone Pages in the database. If your website runs on multiple domains, your URLs will automatically show the current domain in the list.

If you migrate to another domain, you won’t have to update the Cornerstone Pages list – Boost will handle it for you.

Please note that only URLs from the same domain are allowed.

If you load the default pages, you will have to manually save the URLs you added to the list by clicking the Save button.

Trailing slashes

All URLs in the list will be displayed without a trailing slash; even if you add one, Boost will remove it automatically, as the system handles slashes.

When saving the values in the database, a trailing slash will either be added or removed based on your website’s permalink structure.

Removing all pages from the list

You can remove one or more URLs from the list or all of them, then click the Save button to validate the changes. Removing all pages from the list and saving them will automatically add the home page to the list.

If you leave the Cornerstone Pages list empty, the system will consider your homepage a default page to flag and automatically list it there.

Cornerstone Pages benefits for Boost features

The Cornerstone Pages settings can positively influence active Boost features.

Page Speed scores

Page Speed scores will still be measured against your home page.

Critical CSS

When generating Critical CSS, Cornerstone Pages will have their version explicitly tailored to them, rather than the generic critical CSS generated for a group of pages.

For example, if the “About” page on your website has a unique look – different from the rest of the pages on your website – adding it to the Cornerstone Pages list will have Boost generate a Critical CSS specifically for that page’s layout.

Previously, Boost would have generated one Critical CSS that respects both layouts, which meant a wider chunk of CSS on the page.

Page Caching

Jetpack Boost automatically generates cache files for your Cornerstone Pages every 30 minutes via a scheduled WordPress Cron.

This Cache Preloading mechanism ensures your Cornerstone Pages maintain optimal performance by ensuring a cache file for all Cornerstone Pages is always available for visitors to your site.

Prerendering Pages

If your site runs WordPress 6.8 or later, Jetpack Boost includes a toggle to prerender Cornerstone Pages using WordPress’s new Speculative Loading feature.

When enabled, supported browsers (like Chrome, Edge, and Opera) may begin loading Cornerstone Pages in the background as soon as visitors hover over a link. This can result in near-instant page loads when they click.

You can toggle this setting on and off in the Cornerstone Pages section of the Boost dashboard. It’s off by default.

Prerendering pages can be unsafe in certain circumstances. Since the browser fetches the page and renders it in an invisible browser tab, any JavaScript on the page will execute. If the page makes changes on the server, such as making a purchase or subscribing to a mailing list, hovering over a link to that page will be enough for those actions to take place. The MDN web documentation here is a good resource to find out more about this.

Troubleshooting Cornerstone Pages errors

Boost does not allow the list to be updated if there are errors present, so if you encounter any of these errors, you need to correct them before saving any further changes.

ErrorCauseSolution
Page list limit exceededYou added more pages than allowed by your plan.Remove extra pages from the list or upgrade.
URL from a different domainThe URL does not match your current website domain.Use only URLs from your website’s domain.

Feedback

Your feedback is invaluable in helping us improve Boost. If you have feedback about Cornerstone Pages, please don’t hesitate to share it with us!

Still need help?

Please contact support. We’re happy to advise.

Comments Off on Jetpack Boost Cornerstone Pages

Troubleshooting Critical CSS in Jetpack Boost

Posted on June 3, 2024 by Pete

If you encounter an error indicating that Critical CSS isn’t generating as expected, it’s crucial to identify the specific problem based on the error message received.

To check if Critical CSS is working, you can view your page source and look for this line:

<style id="jetpack-boost-critical-css">

To view the page source, right-click anywhere on your site and select View Page Source (or press Ctrl+U / Cmd+U on your keyboard).

If you see that line, Jetpack Boost has successfully added Critical CSS to your site. If it’s missing or if something doesn’t look right, check the troubleshooting page.

Redirect Error

This error occurs when Jetpack Boost is directed to a new URL during Critical CSS generation. This can be caused by:

  • Maintenance mode plugins which redirect to a “coming soon” page.
  • Consent management plugins which redirect to a consent page.
  • URL-rewriting plugins strip GET arguments, resulting in incorrect URLs.

Potential solutions:

  1. Ensure URLs are correctly set, and no unintended redirects are in place.
  2. Temporarily disable maintenance mode plugins to see if the issue is resolved.
  3. Configure consent management plugins to allow Jetpack Boost to access the required pages.
  4. Adjust URL-rewriting plugin settings to prevent altering target URLs.
  5. If the redirection is due to standard HTTP 301/302 redirects, it may be necessary to accept that Critical CSS can’t be generated for those pages.

If the redirection is due to standard HTTP 301/302 redirects, it may be necessary to accept that Critical CSS can’t be generated for those pages.

HTTP Errors

When generating Critical CSS, Jetpack Boost may encounter various HTTP errors. Each error indicates a specific issue that needs to be addressed. Below are the common HTTP errors you might encounter, along with their causes and potential solutions to help you resolve them effectively.

HTTP Error 401, 403

This error indicates a permission issue on your WordPress site.

Potential solutions for HTTP 401/403 errors:

  1. Check your WordPress settings or contact your hosting provider to ask why the URL is unavailable.
  2. Ensure the page is not private and accessible. To do that, open the link in “Incognito Mode” or “Private Browsing” and make sure it loads as expected when you are not logged in.

HTTP Error 404

This error indicates that the requested URL does not exist.

Potential solutions for HTTP 404 error:

  1. Confirm that the page loads successfully.
  2. If the page shows an error, ensure that it is part of your WordPress site and published.
  3. Try visiting the link using “Incognito Mode” or “Private Browsing” to check if the error occurs when you are not logged in.
  4. If you see an error only when not logged in (i.e., in “Incognito Mode”), check for plugins that might be enforcing access permissions on your pages, such as those allowing only authenticated users to view specific areas.

HTTP Error 418 – I’m a Teapot

This is typically used to indicate a request has been rejected due to security rules.

Potential solutions for HTTP 418 error:

  1. Contact your hosting provider with details of the issue, mentioning the HTTP 418 error, affected URL(s), and time of occurrence.
  2. Your hosting provider should advise you on the next steps.

HTTP Error 500 – Internal Server Error

This indicates a server-side error preventing the request from being fulfilled.

Potential solution for HTTP 500 error:

Contact your hosting and ask to check your server logs for detailed error messages.

Cross Domain Error

This occurs when the page is hosted on a different domain, and the server’s security settings prevent it from being accessed or loaded from outside its own domain.

Potential solution for Cross Domain Error: 

Visit the page and check the protocol and hostname to ensure they match those in your WordPress Administration Screen. For example: In http://jetpack.com, the http is Protocol, and jetpack.com is Hostname

Couldn’t verify page (UrlVerifyError)

For Critical CSS to work properly, Boost tries to include a meta tag to the site during critical CSS generation in order to verify the page. If for some reason it fails to add the meta tag, it will return this error.

Potential solutions for Couldn’t Verify Page error: 

  1. The most frequent reasons for this are plugins with maintenance mode turned on and pages that are behind some form of authentication (like a login form).
  2. Make sure you can still access the page when you are not logged in.
  3. If you can, but you still get this error, there may be some form of caching that is preventing Boost from adding the meta generation tag.

Failed to generate Critical CSS

This is a general error that can appear for different reasons. Check the specific error message shown in your Boost dashboard or site logs to identify what’s going wrong.

No relevant CSS found in external stylesheets

Boost relies on external CSS files to generate Critical CSS. If your page doesn’t load any, Boost cannot extract the necessary styles. You may be using an optimization plugin that inlines all CSS instead of loading it from external files.

What to do: You can safely ignore this message if the site is already using inline CSS for performance.

Connection or access issue

Sometimes, Boost fails to reach your site or is blocked from loading pages properly.

Potential solutions:

  • Make sure the website does not load over both HTTP and HTTPS. To fix, direct all website traffic to HTTPS. Your host can help with this, or use a plugin like Really Simple SSL.
  • Check that there are no redirects from the home page, such as from https://testsite.com to https://testsite.com/en. Your host can assist with unwanted redirects.
  • Confirm the site is live and publicly viewable. “Coming Soon” and “Under Construction” pages will prevent Jetpack from generating critical CSS.
  • If you’ve confirmed all of the above and still see a failure, a plugin conflict might be the cause. Conflicting plugins can interfere with the Jetpack connection or block required styles from loading properly. To test for this, follow the plugin conflict test guide.

Potential Conflicts with Other Performance Plugins

Conflicts can occur when another performance or caching plugin — such as LiteSpeed Cache — modifies how CSS is loaded or optimized. These changes may interfere with Jetpack Boost’s Critical CSS generation and cause layout problems, especially after updating the plugin or theme.

Potential solutions:

  • Temporarily disable the Optimize CSS Loading feature from Jetpack → Boost. If the layout returns to normal, the issue may be caused by a conflict with another plugin’s CSS optimizations.
  • If you’re using LiteSpeed Cache, go to LiteSpeed Cache → Page Optimization → CSS Settings, and disable the Load CSS Asynchronously option.
  • As an alternative, consider keeping Jetpack Boost’s CSS optimization off and using your caching plugin’s optimization features instead — or vice versa.
  • You can also try excluding certain stylesheets or classes from optimization in your other plugin, if supported.

If you’re unsure which plugin is causing the issue, disable them one by one and retest the layout each time.

Load Timeout Error

This might happen because of a redirect loop that might be caused by a misconfiguration of the server or some plugin (or custom code) misbehaving. We’ve also seen instances of ads taking too long to load and Boost times out while waiting for them.

Potential solutions for Load Timeout error:

  1. Clear the cache in your browser to ensure Boost loads the most recent version of the page.
  2. Visit the page while not logged into WordPress to see if the issue persists.
  3. Check how long it takes for this page to load compared to other pages on your site.
  4. If this page is slower than others, identify which plugins are active on that page.
  5. Deactivate any plugins that you believe are causing the page to load slowly.

XFrameDeny Error

Jetpack Boost uses iframes to generate your critical CSS. This error occurs when the site has a special configuration header that prevents it from loading inside an iframe. The header is called X-Frame-Options: DENY. This can be added to a WordPress site either by a plugin or by server configuration.

Potential solutions for XFrameDeny Error:

  1. Ensure you are not using any plugins that add extra HTTP headers to your WordPress site, and deactivate them if you are.
  2. If you are unsure what these headers are, or where they come from, please contact your hosting provider and ask them to remove the X-Frame-Options header from your site.

InvalidURL Error

Jetpack Boost found one or more invalid URLs while trying to generate Critical CSS. Please note, that it’s sometimes okay to ignore such URLs. There are many reasons why this can happen, so it’s hard to provide a solution that works every time.

Potential solutions for InvalidURL Error:

  1. Make sure any custom rewrites you have on your website are working properly.
  2. There might be a plugin active that’s causing one or more URLs to become invalid. Go through the list of plugins and deactivate such plugins until the problem is resolved.

Provider Error

This happens when something prevents Jetpack Boost from saving the Critical CSS that it generated for a specific group of pages. This is most often because of a Web Application Firewall (WAF), or a security plugin blocking the request.

Potential solutions to the Provider Error:

  1. See if you have any security plugins and disable them. After that, check if generation works by running it again. If it works, see if you can add an exclude rule in the security plugin for URLs containing set-provider-css.
  2. If you do not have security plugins installed, your hosting’s WAF might be blocking the request. You can check this by running this curl command in a terminal/command prompt (make sure to replace https://website.com/ with your website’s URL):
    curl --location 'https://website.com/' \ --data '<svg xmlns'
  3. If the above command shows Forbidden, you’ll need to contact your hosting provider and ask them to unblock the request.

Broken generation library

This is unlikely to happen, but we have a case if it does. If Boost’s critical CSS generation library somehow gets corrupted or some other plugin is interfering, this error will show up.

Potential solutions for Broken generation library error:

  1. Toggle the module off and on to see if the error persists.
  2. If it persists, reinstall Jetpack Boost to make sure that all its files are okay.
  3. If reinstalling doesn’t help, it’s possible that some other plugin is causing a conflict. In that case, disable the plugins one by one until the problem is resolved.

Expected an associative array, received ‘NULL’

This error can appear when Boost fails to generate Critical CSS due to a server-side issue during the request.

Potential solution for ‘NULL’ error:

  • This may be caused by a misconfiguration or problem with your host’s Memory Node.
  • Reach out to your hosting provider and ask them to check if the Memory Node is working properly.
  • If you’ve recently installed or updated plugins, or if Boost previously worked fine, a temporary server issue might be the cause.
  • If you’re using Cloudflare, try temporarily disabling it to see if that resolves the error.

Once the server issue is resolved, you should be able to regenerate Critical CSS successfully.

PayloadTooLargeError

This error appears when the generated Critical CSS exceeds 1MB. Quite often, this happens on pages that are built using page builder plugins.

If Jetpack Boost were to include the Critical CSS, that would make the page heaver and actually slow it down. As a result, it’s intentionally not included. It’s even not saved on your website.

Potential solutions for PayloadTooLargeError:

  1. See if you can update your pages to share the same blocks.

By having pages share the same layout, you make sure that the generated Critical CSS will be smaller.

If sharing the same blocks isn’t an option and the layout of the pages is too unique, then you can’t take advantage of the Critical CSS feature on the pages in that group.

Unknown Error

This occurs when an unexpected error occurs while trying to generate Critical CSS for the specified page. Jetpack Boost did not anticipate this issue.

Potential solutions for Unknown Error:

  1. Open the URL to check if the page loads correctly.
  2. Ensure the page is loading without any errors or issues.
  3. If the page loads correctly but Critical CSS still fails, please contact us so we can investigate further.

By identifying the specific issue based on the error message and following these solutions, you can address common problems with Jetpack Boost’s Critical CSS feature, ensuring your site loads efficiently and provides an optimal user experience.

Still need help?

Please contact support. We’re happy to advise.

Comments Off on Troubleshooting Critical CSS in Jetpack Boost

Exclude JavaScript files from Jetpack Boost deferral

Posted on February 8, 2024 by Adnan Haque

If you experience unwanted website behavior when you defer JS with Jetpack Boost, the affected functionality could rely on the JavaScript files being in a certain order or being made available to the page as soon as possible.

In such cases, you can tell Jetpack Boost not to defer those specific files by adding the attribute data-jetpack-boost="ignore" to the script tag.

Example (if your script tag is hardcoded):

<script data-jetpack-boost="ignore">

If your script tag is enqueued with wp_enqueue_script like the following:

function wpdemo_enqueue_scripts() {
    wp_enqueue_script( 'wpdemo', get_template_directory_uri().'/js/wpdemo.js' );
}
add_action( 'wp_enqueue_scripts', 'wpdemo_enqueue_scripts' );

You can use the example snippet below and add it to your themes functions.php file:

function add_data_jetpack_boost_tag( $src, $handle ) {
    if ( $handle !== 'wpdemo') {
        return $src;
    }
    return str_replace( ' src', ' data-jetpack-boost="ignore" src', $src );
}
add_filter( 'script_loader_tag', 'add_data_jetpack_boost_tag', 10, 2 );

Remember to replace wpdemo with the handle of the script file you want to exclude.

Comments Off on Exclude JavaScript files from Jetpack Boost deferral

Site Accelerator

Posted on November 5, 2018 by Paulina Hetman

Speed up your website’s loading time by optimizing your images and common static assets by serving them from our global network of servers.

Jetpack’s Site Accelerator (a.k.a. Jetpack content delivery network or CDN, formerly known as Photon) helps your pages load faster by optimizing your images and serving them alongside static files (like CSS and JavaScript) from our global network of servers.

For general features and FAQs, please see our CDN features here.

Activate Site Accelerator

Site Accelerator is deactivated by default. To activate it, please follow these steps:

  1. In your site’s dashboard, go to Jetpack → Settings → Performance.
  2. In the Performance & speed section, toggle on
Screenshot of the Performance & Speed dashboard in Jetpack.

Once you turn on Site Accelerator, please keep your photos on your server for the CDN to work correctly. We only make copies, and any images that are removed from your server will eventually “expire” and be removed from our CDN.

If you ever turn off Site Accelerator, images will continue to show on your website, they will just start loading from your webhost’s server again instead of ours. Please note that it could take a few minutes for these changes to take place.

Check that Site Accelerator is working

To check if images are loading from the CDN, you can follow these steps:

  1. Wait a few moments and then load your site in a different web browser, to avoid any caching issues.
  2. Check an image’s URL in your browser’s inspector, or open the image in its own tab. The images served from our CDN have URLs that begin https://i0.wp.com, https://i1.wp.com, https://i2.wp.com or similar.
  3. If you do not see i0.wp.com or similar, see our troubleshooting steps below.

How Site Accelerator works

Image load times

Our Image CDN is an image optimization and editing service. We copy your photos and then host them from our servers, alleviating the load on your server and providing faster image loading for your readers.

Static file load times (Asset CDN)

The Asset CDN serves a limited set of static files only from WordPress core, Jetpack, and WooCommerce via our global network of servers. This reduces the load on your server for these specific assets.

  • It does NOT serve: static files from themes, third-party plugins, or custom scripts.
  • If you disable Site Accelerator, only WordPress core, Jetpack, and WooCommerce assets will revert to loading from your local server. Theme and plugin assets are not affected, as they were never served by Jetpack’s CDN.
  • Site accelerator filters the URLs of assets that are loaded with every WordPress page.
  • Site accelerator only acts on assets shipped with WordPress core, Jetpack, and WooCommerce.

What happens when you disable Site Accelerator?

If you turn off Site Accelerator:

  • Images will still load on your site but will no longer be served via Jetpack’s CDN.
  • WordPress core, Jetpack, and WooCommerce assets will switch back to loading from your site’s local server.
  • Theme and plugin files were never served by Site Accelerator. They will continue to load exactly as before.
  • If your site breaks after disabling Site Accelerator, check for:
    • Caching conflicts – Clear your browser and site cache (both plugins and server-side caching)
    • Missing assets – Ensure all theme and/or plugin files exist on your local server.
    • Dependencies – Some themes or plugins might expect assets to load from Jetpack’s CDN. If disabling causes problems, check with the theme or plugin developer.

Allow the Photon User Agent to Ensure Site Accelerator Works

Jetpack’s Site Accelerator (also known as the Image CDN) relies on accessing your images using a special user agent: Photon/1.0. If this user agent is blocked—by a security plugin, server rules, or firewall—Jetpack will not be able to fetch your images, and they will not be served via Site Accelerator.

Common causes of blocking:

  • Security plugins may block the Photon user agent by default.
  • Custom .htaccess rules may include blocks for unknown or bot-like user agents.
  • Firewall settings may filter or deny requests from Photon/1.0

To fix this issue:

  1. Look for .htaccess or firewall rules that may include a line like:
  2. Check any active security or optimization plugins for user agent filtering features.
  3. If present, remove it or adjust the rule to allow Photon/1.0.
  4. If you must use user agent filtering, make sure to allowlist Photon/1.0 and Jetpack requests.
  5. Optionally, allow Jetpack’s IP ranges if server-level filtering is applied.

When this is misconfigured, you may see:

  • Images not loading from i0.wp.com, i1.wp.com, etc.
  • Broken images or timeouts in the browser.
  • A 403 or empty response for requests from Jetpack servers.

Image resizing

Site Accelerator resizes photos by first checking the img element’s width and height attributes and then serving an image resized to those dimensions, or to the width of the containing element (whichever is smaller).

If there is no size set on the element, Jetpack will constrain images to the size indicated when adding the image to a post, or to your theme’s “content width” setting.

Finally, if a content width isn’t set in your theme, then Site Accelerator will default to 1,000px. This is to help ensure that sites are not trying to serve images larger than what the theme intended to be able to display.

We remove the width and height arguments to prevent your images from skewing when the resized image doesn’t have the same dimensions as the original. This is particularly important when you switch from one theme to another, and the new theme might be narrower than the previous one. One of the benefits of this is that we will automatically resize your images so they don’t exceed the width supported by your theme.

Limitations of Site Accelerator

Cache and theme/plugins

  • Site Accelerator will not fetch or process images larger than 50 MB in size.
  • Site Accelerator does not do cache invalidations. Static assets are tied to the public version of WordPress, Jetpack, or WooCommerce that you’re using. For images, if you want to “refresh” an image, you will need to change its file name. Adding random query arguments, commonly known as “cache busters,” will not work.
  • Theme and plugin assets are not supported by Site Accelerator at this time.
  • Themes and plugins can also use the Photon API to transform images using GET query arguments. Developers will find Photon API examples and documentation on developer.wordpress.com.

Self-served image purge

It is not possible to automatically purge or delete all cached site images from Jetpack servers.

If there is an image that is no longer on your server and you’d like us to remove it, please contact Jetpack support with a direct link to the file as it appears on your site. Cached image links usually begin with i0.wp.com, i1.wp.com, i2.wp.com, or i3.wp.com.

Since images can only be purged or deleted manually by individual URL, there is a limit to how many we can remove. Bulk purges or whole-site deletions for cached images are not possible.

Size edit, and type of files

  • We will not “upscale” an image in most circumstances. If your original image is 1,000px wide and you ask for Jetpack to make it 5,000px, we will serve the original 1,000px image. Upscaled images are usually of poor quality, and we want to avoid that.
  • Site Accelerator only handles GIF, PNG, JPG, and WebP images from servers that listen on port 80 for HTTP and port 443 for HTTPS. This applies to about 99.99% of the web servers in the world. If you are having issues, please try using the jetpack_photon_reject_https filter.
  • Site Accelerator does not support animated PNGs.
  • Site Accelerator does not serve audio (.mp3, .wav, .flac, etc.) or video (.mp4, .wmv, .flv, etc.) files. If you’d like to host videos on our CDN, check out our Video Hosting feature.

Server time out and serving image location

  • If your server takes longer than 10 seconds when an image is being retrieved for our CDN, the process will time out and your image will appear to be broken. Try to upload a differently-named image with a smaller dimension or file size if this happens.
  • It’s not possible to choose or limit where in the world your images will be served from. We have servers placed all over the world, and which server will load your image is dependent on a variety of factors, including the visitor’s location.

Site Accelerator is only allowed to be used by sites hosted on WordPress.com or on Jetpack-connected WordPress sites. If you move to another platform or disconnect Jetpack from your site, please also switch to another image CDN service. Any abuse of Jetpack or violation of the WordPress.com Terms of Service could result in the suspension of your site from WordPress.com-connected services, including Site Accelerator.

Troubleshooting Site Accelerator

My images don’t load

  1. Wait a few minutes and reload your site in an incognito/private browsing window. It may take time for changes to apply.
  2. Right-click an image and open it in a new tab. If the URL doesn’t start with i0.wp.com, i1.wp.com, or similar, image acceleration isn’t active.
  3. Make sure Jetpack is properly connected to WordPress.com.
  4. Some image optimization plugins may conflict with Site Accelerator by altering image URLs or introducing lazy loading mechanisms. Disable all other plugins except Jetpack and check if the issue resolves. If images display properly, re-enable plugins one by one to identify the conflicting plugin.
  5. If images still aren’t loading, switch to a default WordPress theme (e.g., Twenty Twenty-Four) to check for a theme conflict.

The static assets don’t load after disabling Asset CDN

  1. Clear your browser cache and site cache to remove any outdated references to Jetpack’s CDN.
  2. Check if the missing files exist on your local server. If they’re missing, try reinstalling WordPress core, Jetpack, or WooCommerce. If the issue persists, check for incorrect file paths or conflicts with caching plugins.
  3. If using a caching plugin, purge the cache and reload your site. Some plugins may still be referencing the old CDN URLs.
  4. Disable all other optimization plugins and test again. Some caching/minification tools may interfere with asset delivery.
  5. If issues persist, temporarily re-enable Site Accelerator and check if the problem is resolved. This helps confirm whether the issue is related to disabling the CDN.

Site Accelerator and User Agent Filters

Site Accelerator requires Jetpack to access your images using a specific user agent, Photon/1.0. If this user agent is blocked by a plugin, firewall, or server configuration, Jetpack will not be able to retrieve or cache your images. This prevents Site Accelerator from functioning correctly.

Why this matters

Jetpack’s Site Accelerator fetches and optimizes images directly from your server. This process depends on the `Photon/1.0` user agent being allowed. If it’s blocked, Jetpack cannot deliver your images via its CDN even if the feature is enabled.

Signs that the Photon user agent may be blocked

  1. Images are not loading from Jetpack CDN domains like i0.wp.com, i1.wp.com, etc.
  2. You see 403 or timeout errors in your browser’s network tools.
  3. Site Accelerator appears enabled but has no visible effect on image delivery.

How to check for and resolve user agent blocks

Check for plugin, firewall, or server rules that may be filtering or blocking user agents. Security tools like Blackhole for Bad Bots or WP-Optimize have been known to interfere with Jetpack in this way.

To verify, look for code similar to the following in your .htaccess file:

# Block Photon

RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} Photon/1.0 [NC]
RewriteRule .* - [F,L]

If this rule is present, Site Accelerator will not be able to access your images. You’ll need to remove or modify the rule to allow the Photon/1.0 user agent.

If you use stricter user agent filtering, we recommend allowlisting Photon/1.0 and optionally Jetpack’s IP ranges to avoid unintended blocking.

We provide this example for reference only. Per our Scope of Support, we cannot assist with implementing or troubleshooting custom server rules.

Still need help?

Please contact support. We’re happy to advise.

Privacy Information

Site Accelerator is deactivated by default. You can toggle the feature on or off under the Performance & speed section from Jetpack → Settings → Performance in your dashboard.

Data Used
Site Owners / Users

While not actively used in the delivery of this functionality, EXIF data may exist (and be accessible to site visitors) in any of the images that you upload to your site.Additionally, for activity tracking (detailed below): IP address, WordPress.com user ID, WordPress.com username, WordPress.com-connected site ID and URL, Jetpack version, user agent, visiting URL, referring URL, timestamp of event, browser language, country code.

 Site Visitors

None.
Activity Tracked
Site Owners / Users

We track when, and by which user, the feature is activated and deactivated.

 Site Visitors

None.
Data Synced (Read More)
Site Owners / Users

We sync a single option that identifies whether or not the feature is activated.

 Site Visitors

None.

Comments Off on Site Accelerator

  • Enter your email address to receive news and updates from Jetpack

  • Join 99K other subscribers

  • Browse by Topic