Core Web Vitals on ThemeForest WordPress themes: what to fix first
Written by AERVIO, a Montreal studio. Human-reviewed before publish. Contact: hello@aervio.io · +1 438-498-3913.
ThemeForest multipurpose themes usually fail Core Web Vitals for the same reasons: they load scripts, styles and fonts for features you do not use, they ship large page-builder layers, and their demo content pushes oversized images into the first screen. The fix order is: measure real-user data, remove unused weight, fix the largest element, stabilise layout, then decide whether the theme is worth keeping. Chasing a lab score first is how teams spend a week and change nothing visitors feel.
AERVIO is a Montreal studio, weekdays 9–17 ET. This is the sequence we use when a business site on a purchased theme is slow and the owner does not want a rebuild unless one is warranted.
What the three metrics mean in plain terms
- LCP (Largest Contentful Paint): how long until the biggest visible element, often a hero image or headline, is on screen. Good is 2.5 seconds or less.
- INP (Interaction to Next Paint): how quickly the page responds after a tap or click. Good is 200 milliseconds or less.
- CLS (Cumulative Layout Shift): how much the layout jumps while loading. Good is 0.1 or less.
Google evaluates them at the 75th percentile of real visits, which means a quarter of your visitors can have a worse experience and the page can still pass. See web.dev's Web Vitals guide for current definitions.
Why ThemeForest themes struggle
Themes are built to sell on a demo page, so they include everything a buyer might want.
| Typical theme habit | Effect on vitals |
|---|---|
| Dozens of bundled sliders, animations, icon sets | More JavaScript and CSS on every page |
| Bundled page builder plus theme-specific add-ons | Large DOM, heavy main thread work |
| Hero sliders and video backgrounds | Slow LCP, layout shifts |
| Multiple Google Fonts and icon fonts | Render delay, invisible text, shifts |
| jQuery plugins for effects | Slow interaction on mid-range phones |
| Demo images imported at full size | Heavy pages, large LCP image |
| Plugins that inject assets everywhere | Contact form scripts on pages with no form |
None of this is malicious. It is the cost of general-purpose design.
Step 1: Measure the right thing
Start with field data where it exists.
- Search Console, Core Web Vitals report: groups URLs by status for mobile and desktop.
- PageSpeed Insights: shows real-user data (when available) above the lab test.
- Lab tools (Lighthouse, WebPageTest): useful for diagnosing causes, not for declaring victory.
Test your money pages: home, a service page, a contact page and the most-visited post. Do not average the whole site. A fast blog and a slow contact page is still a slow contact page.
If a URL has too little traffic for field data, rely on the lab test, but test on a throttled mobile profile, not your office fibre.
Step 2: Remove what loads and is not used
This is usually the biggest win and the cheapest.
- List every plugin and the pages it actually serves.
- Deactivate plugins you do not use.
- Use an asset manager to stop scripts and styles loading where they are not needed, for example forms on pages with no forms.
- Turn off theme modules (sliders, portfolios, mega menus) you do not use.
- Remove demo content and unused widgets.
Retest after each change. If a change breaks something, you will know which one.
Step 3: Fix LCP
Find the LCP element in the test results. It is usually one of these:
- A hero image. Resize it to the displayed size, serve a modern format such as WebP or AVIF, and avoid lazy-loading the image that is first on screen. Consider preloading it if it is discovered late.
- A slider. Replace it with one static image and a clear headline. Sliders are rarely read past the first slide.
- A heading in a custom font. Reduce font files and use a sensible fallback while loading.
- A background video. Replace with a poster image, or remove.
Slow server response also inflates LCP. Check hosting, caching and whether the page is built from heavy database queries on each visit. This is where a page cache and decent hosting matter more than any theme setting.
Step 4: Fix INP
INP problems come from JavaScript doing too much when a person interacts.
- Remove third-party widgets you do not need (chat, popups, social feeds)
- Delay non-critical scripts until after first interaction
- Replace animated menus with simpler ones
- Reduce page-builder nesting that creates huge DOMs
- Test on a mid-range Android phone, not a developer laptop
If the cause is the theme's core JavaScript and you cannot disable it, that is evidence for the "replace" conversation.
Step 5: Fix CLS
Layout shift is rarely mysterious.
- Add width and height (or aspect ratio) to images and embeds
- Reserve space for ads, cookie banners and chat widgets
- Load fonts with `font-display` settings and matched fallbacks
- Avoid injecting banners above existing content after load
Cookie and consent banners are common culprits. They should overlay or be given reserved space, not push the page down.
Step 6: Decide: tune, slim or replace
After the above, you have three honest choices.
| Choice | When it fits |
|---|---|
| Tune | Scores improved, remaining issues are minor |
| Slim down | Replace the page builder or heavy modules, keep content |
| Replace | The theme's core code is the bottleneck and cannot be disabled |
Replacement does not have to mean a different CMS. A lean WordPress theme built for your layouts often solves it. When the real question is editors, stack and long-term ownership, we cover it in Next.js or WordPress for Quebec businesses.
How this connects to search and AI answers
Speed is one part of page quality. Google also looks at whether the page answers the query, whether the content is useful and whether the site is crawlable. A quick page with vague copy will not become visible because it passes a test. We treat performance, content and local signals as one system, and our approach to local visibility is in SEO and GEO in Montreal.
We do not guarantee rankings. We can guarantee the measurement, the list of changes and what we found.
What to expect in the first week
- Day 1: collect Search Console data and test the top five URLs
- Day 2: plugin and asset inventory
- Day 3: remove and defer what is unused, retest
- Day 4: images, fonts and LCP element
- Day 5: INP and CLS review, then a written recommendation
Some themes improve a lot. Some improve a little and need a rebuild of the template layer. The report tells you which.
Next step
Send hello@aervio.io your site URL, the theme name and your Search Console Core Web Vitals screenshot, or call +1 438-498-3913, weekdays 9–17 ET. We will tell you whether this is a tuning job or a rebuild. Our SEO and GEO services page explains how we combine technical fixes with pages worth citing.
Questions
What are the Core Web Vitals thresholds?
Google's guidance treats a page as good when, at the 75th percentile of real visits, Largest Contentful Paint is 2.5 seconds or less, Interaction to Next Paint is 200 milliseconds or less, and Cumulative Layout Shift is 0.1 or less. Check web.dev for the current definitions.
Will fixing Core Web Vitals improve our rankings?
It can help, but we do not promise it. Page experience is one signal among many, and relevance matters more. A fast page that answers the wrong question will not rank for it. Fast pages do reduce abandonment, which is the more reliable business reason to fix them.
Should we replace our ThemeForest theme?
Not automatically. Measure first, remove what you do not use and test. If the theme still blocks you after that, a lighter build is justified. Replace on evidence, not on a score.
Let's write the next step.
