If your site runs Ezoic, every page passes through two systems before a visitor sees it: our server, where WordPress builds and caches the page, and Ezoic’s network, where ads are inserted and Leap applies its own speed settings. Both can optimise images, scripts and CSS. Doing the same job in both places, or in the less efficient one, is a common reason an Ezoic site feels slow. This article explains how the layers fit together, which Leap settings are usually best left off and what to send us if you need help.
How a page reaches the visitor
- WordPress on our server builds the page. Your caching plugin stores a finished copy, so most visitors are served that copy without WordPress running again.
- The page passes through Ezoic, which inserts the ad code and, if Leap is enabled, rewrites the HTML to apply whichever optimisations are switched on.
- Depending on how Ezoic is connected to your site, Cloudflare may also be in the path.
Work done at step 1 happens once per cache refresh. Work done at step 2 happens as pages pass through each Ezoic location, and again whenever that cache is cleared. Leap has to process a page before it can send it on, so every setting enabled there adds processing on top of the ad insertion Ezoic already does.
Do the work once, on the server
Image compression and WebP conversion are the clearest example. Converted in WordPress, each image is processed once and stored on the server. Converted at a CDN layer, the work repeats at each location and after each cache clear. Script delay and CSS optimisation follow the same logic: let a plugin produce the optimised page, let the page cache hold it, and keep Ezoic’s job small.
Leap settings usually best switched off
- Minify: it interferes with caching and is often slow. If you want minification, Cloudflare’s option is the better place, and the gain is small either way.
- Image options (lazy loading, next-gen formats, resizing, background image preloading): use Autoptimize for lazy loading, EWWW Image Optimizer for WebP, and WP Rocket if you need image dimensions added.
- Script execution options, including reducing CPU intensive tasks: in the video this option was rewriting JavaScript and slowing the whole page. Script delay belongs in your WordPress optimisation plugin.
- CSS optimisation: leave it to WP Rocket or Autoptimize. If your theme is already lean (the site in the video runs GeneratePress), extra CSS processing adds time without benefit.
- Font optimisation: unnecessary if WP Rocket already handles fonts.
- Iframe lazy loading: in the video it stopped a YouTube embed working. WP Rocket’s iframe lazy loading, with the YouTube thumbnail option, did the job without breaking anything.
Settings worth keeping on
Preconnect opens connections to the ad servers early, so ads arrive a little sooner, and it costs nothing meaningful. Ezoic’s ad handling (speeding up ad code and lazy loading ads) is the main reason to use it and is not something WordPress can do for you, so leave that in place.
Static cache policy and time to first byte
Time to first byte (TTFB) is how long the browser waits before the first byte of the page arrives. It includes our server returning the page plus every layer in between. The video found that Leap’s static cache policy setting made little difference because the site was already sending cache headers. If TTFB is poor on an Ezoic site, turning that setting off and letting Cloudflare handle caching is worth testing.
When TTFB is slow, the first question is which layer is responsible. We can check how quickly the server itself returns the page and confirm the page cache is being hit, which separates a hosting delay from one introduced further along the chain.
After changing settings
- Clear every cache: your WordPress caching plugin, the server cache from the hosting panel if you use it, Ezoic’s cache, and Cloudflare’s if it is in the path.
- Check pages by hand: videos play, images load, ads appear, menus and forms respond.
- Retest in PageSpeed Insights and compare with your earlier results. Scores vary between runs and test locations, so test the same pages from the same place each time.
When to open a ticket
Open a ticket from the client area if pages are still slow to start loading after you have trimmed Leap, if something broke after a settings change and clearing caches did not fix it, or if you are not sure which plugin is doing what. Include:
- Two or three example URLs, ideally the homepage, a typical article and a category page.
- Which Leap settings are on and off (a screenshot of the panel is fine).
- The optimisation and caching plugins active in WordPress.
- How Ezoic is connected to the site, for example through nameservers or the Cloudflare integration, and whether Cloudflare is also in use.
Our support team can look at the server and WordPress side. Changes inside the Ezoic dashboard are made from your own Ezoic account.
