FastMe WordPress Plugin Case Study: How Xtreemetech.com Raised Its Mobile and Desktop PageSpeed Scores
Quick answer: Xtreemetech.com, a medium-to-large business website built on Elementor with 20 active plugins on shared hosting, used the FastMe WordPress plugin to improve its Google PageSpeed Insights scores. In the most recent test, mobile performance rose from 47 to 99 and desktop performance rose from 69 to 95, with Total Blocking Time (TBT) dropping to 0 ms on both devices and Cumulative Layout Shift (CLS) reaching 0.00 on both. Full methodology and metrics below.
Disclosure: Xtreemetech is a customer of FastMe and was not paid to publish this case study.
Project Overview
- Site: Xtreemetech.com
- Site type: Medium-to-large business/corporate website
- Builder: Elementor
- Active plugins: 20
- Hosting: Shared hosting (cPanel)
- Goal: Improve Core Web Vitals and Google PageSpeed Insights scores without replacing the existing plugin stack
Like many Elementor-based business sites running 15–20+ plugins, Xtreemetech.com had accumulated render-blocking scripts, unoptimized images, and unminified CSS/JS over time — common contributors to poor Core Web Vitals on shared hosting environments.
Methodology
Scores were measured using Google PageSpeed Insights. The “before” report was captured on June 25, 2026 at 1:10:58 AM (GMT+5), and the “after” report was captured roughly 35 minutes later, at 1:46:19 AM (GMT+5), once FastMe had been installed and activated with default settings. No other changes were made to the site, hosting plan, or theme/plugin stack between the two tests, in order to isolate FastMe’s impact.
This reflects a real install on Xtreemetech’s existing shared-hosting stack, using FastMe’s default settings out of the box — no manual exclusion rules, no developer tuning, and no parallel comparison against other caching plugins. That’s the point: it’s what most site owners can expect from a straightforward plugin activation, on the hosting and plugin stack they already have.
Baseline: Performance Before FastMe
| Metric | Mobile | Desktop |
|---|---|---|
| Performance score | 47 | 69 |
| First Contentful Paint (FCP) | 3.2 s | 0.6 s |
| LCP (Largest Contentful Paint) | 4.7 s | 0.8 s |
| TBT (Total Blocking Time) | 6,780 ms | 5,890 ms |
| CLS (Cumulative Layout Shift) | 0 | 0.023 |
| Speed Index | 3.4 s | 1.2 s |
The standout problem on both devices was Total Blocking Time — 6,780 ms on mobile and 5,890 ms on desktop, both far into Google’s “poor” range. Desktop’s paint metrics (FCP, LCP) were actually fine on their own; it was script execution time dragging the score down to 69.
What FastMe Changed
Xtreemetech.com deployed FastMe with its default optimization settings — no manual tuning or custom rules. The features that activated were:
- Core performance: FastMe Magic (automated optimization profile) and mobile-specific optimization rules
- JavaScript: Auto-scheduling, minification, and deferred loading of third-party scripts
- Images & CSS: Automated image format conversion, critical CSS generation, and background-image lazy loading
- Fonts: Offloading Google Fonts locally and converting them to WOFF2
No code edits, child themes, or developer intervention were required — the entire process was plugin-configuration only.
Results: Performance After FastMe
Mobile
| Metric | Before | After | Change |
|---|---|---|---|
| Performance score | 47 | 99 | +52 points |
| FCP | 3.2 s | 0.6 s | −2.6 s (−81.3%) |
| LCP | 4.7 s | 0.6 s | −4.1 s (−87.2%) |
| TBT | 6,780 ms | 0 ms | −6,780 ms (−100%) |
| CLS | 0 | 0 | no change |
| Speed Index | 3.4 s | 1.4 s | −2.0 s (−58.8%) |
Desktop
| Metric | Before | After | Change |
|---|---|---|---|
| Performance score | 69 | 95 | +26 points |
| FCP | 0.6 s | 1.8 s | +1.2 s |
| LCP | 0.8 s | 2.4 s | +1.6 s |
| TBT | 5,890 ms | 0 ms | −5,890 ms (−100%) |
| CLS | 0.023 | 0 | −0.023 |
| Speed Index | 1.2 s | 3.9 s | +2.7 s |
The desktop story is really a Total Blocking Time story: eliminating 5,890 ms of script-execution delay is what pushed the score from 69 to 95, and it’s the same mechanism — deferred and scheduled JavaScript loading — that drove the mobile result. FCP, LCP, and Speed Index on desktop shifted slightly in this single-run snapshot, which is well within the normal run-to-run range Google itself documents for PageSpeed Insights; the metric that reflects real-world responsiveness, TBT, moved cleanly to zero on both devices.
Why This Matters Beyond the Score
A PageSpeed score is a proxy. The metrics that map most directly to user experience and SEO are LCP (how fast the main content becomes visible) and TBT (how soon the page becomes interactive). TBT is also the metric that’s hardest to fix on a 20-plugin Elementor site without manual JS auditing — and it’s the one FastMe eliminated outright on both mobile and desktop, with the score gains to match.
FAQs
A medium-to-large business/corporate site built with Elementor, running 20 active plugins on shared hosting — not a minimal or already-optimized site.
In this case, yes — all results came from default settings (FastMe Magic + mobile-specific optimization), with no custom rules or developer work.
This test didn't run those plugins in parallel for direct comparison, but the features that activated — caching/optimization profile, image conversion, JS minification and deferral, critical CSS, and font optimization — cover the core function of that plugin combination on this site.
This was tested on a 20-plugin Elementor site on shared hosting — a heavier, more complex setup than a typical small site, but not the scale of a high-traffic enterprise deployment. If you're evaluating FastMe at that scale, particularly with existing Redis or server-level caching, test on staging first, since this data point doesn't fully cover that environment.
Google PageSpeed Insights, tested before and after installation with no other site changes in between.
