My website speed optimization services are for site owners whose pages feel slow, whose Core Web Vitals report is red or amber, and who have already tried a caching plugin without much change. I find the real cause of a poor LCP, INP or CLS score, fix it in order of impact, and confirm the improvement in real-user field data rather than one lab test.
Who this is for and what it fixes
Page speed is both a ranking signal and a conversion factor: slow pages lose visitors before they see your offer. Most slow sites share the same handful of root causes, and most speed plugins only hide them. I usually get contacted in one of these situations:
- Google Search Console shows “Poor” or “Needs improvement” URLs under Core Web Vitals, on mobile, desktop or both.
- PageSpeed Insights scores look fine in the lab section but the field data at the top still fails.
- The site feels sluggish when people tap menus, filters or add-to-cart buttons.
- Content jumps around while the page loads, so visitors tap the wrong thing.
- The site slowed down after a theme change, a page builder update, new tracking scripts or a move to cheaper hosting.
- Ads or campaigns are sending traffic to landing pages that take several seconds to show anything useful.
Speed is one part of technical SEO. If your problems are mainly crawling and indexing, that service is the better starting point. This page is purely about making pages load and respond faster.
The three Core Web Vitals and what usually breaks them
Google assesses Core Web Vitals on the 75th percentile of real visits from Chrome users, over a rolling 28 days. That is why a fix can look instant in a lab tool but take weeks to show in Search Console. My guide to Core Web Vitals covers the background; here is what I typically find behind each metric.
| Metric | Good threshold | Common causes I find | Typical fixes |
|---|---|---|---|
| LCP (Largest Contentful Paint) | 2.5 seconds or less | Slow server response, oversized hero images, sliders, lazy-loading the main image, render-blocking CSS and fonts | Server and page caching, CDN, correctly sized WebP or AVIF images, preloading the LCP image, removing lazy-load above the fold, critical CSS |
| INP (Interaction to Next Paint) | 200 milliseconds or less | Heavy JavaScript, page builder bundles, chat widgets, tag manager containers full of old tags, long tasks on the main thread | Removing or delaying third-party scripts, splitting long tasks, loading scripts only where used, trimming tag manager |
| CLS (Cumulative Layout Shift) | 0.1 or less | Images and embeds without dimensions, web fonts swapping late, cookie banners and promo bars pushing content down, ads without reserved space | Width and height attributes, reserved slots, font loading strategy, overlay banners instead of inserted ones |
INP replaced First Input Delay in March 2024. Many sites that passed under FID now fail INP, because INP measures every interaction during the visit rather than just the first one.
Where speed problems usually come from
- Unoptimised images: full-resolution photos served at thumbnail size, no modern formats, no responsive srcset.
- Plugin and script bloat: every page loading assets for features that only run on one page, such as sliders, forms and galleries.
- Render-blocking CSS and JavaScript: the browser waiting on files it does not need yet before it can paint the page.
- Third-party tags: analytics, heatmaps, chat, review widgets and ad pixels, often duplicated across a theme and a tag manager.
- Weak hosting: shared hosting with no server-level caching and a slow time to first byte under normal traffic.
- No CDN: every visitor, wherever they are, pulling assets from one server. This matters a lot for a site hosted in Europe serving visitors in the Gulf or Pakistan, and the reverse.
I explain the hosting side in more detail in hosting, caching and CDNs for speed, and give a non-technical overview in this plain-English speed guide.
My speed optimisation process
| Step | What I do | What you get |
|---|---|---|
| 1. Field data first | Pull Core Web Vitals from Search Console and the Chrome UX Report, grouped by template: homepage, category, product, post, landing page. | A clear view of which templates fail, on which device, and on which metric. |
| 2. Diagnose | Lab testing with Lighthouse, WebPageTest and Chrome DevTools performance traces to find the LCP element, long tasks and layout shift sources. | A short diagnosis per template naming the actual cause, not a list of generic warnings. |
| 3. Fix by impact | Start with what moves the failing metric fastest, usually server response, the LCP image and third-party scripts. | Changes made on staging first, then live, with a change log. |
| 4. Verify | Re-test in the lab, then track field data as the 28-day window rolls over. Request validation in Search Console. | Before and after measurements from your own data. |
| 5. Guard against regressions | Notes on which plugins, scripts and image habits to avoid, plus optional monthly checks. | A site that stays fast after the next update. |
Platform specifics
WordPress and WooCommerce
Most of my speed work is on WordPress. The usual pattern is a multipurpose theme or page builder, 30 or more plugins, and a caching plugin set up with default options. I audit plugins by what they load on each template, configure caching and asset loading properly, and fix builder output where possible. My Elementor technical fixes guide covers one of the most common builders.
Shopify and hosted platforms
You cannot control the server on Shopify, so the work focuses on theme code, app scripts that stay loaded after an app is uninstalled, image handling and third-party tags. For stores, I often combine this with ecommerce SEO, since product and collection templates carry most of the revenue.
Custom and JavaScript frameworks
For React, Next.js, Vue or custom builds, I work with your developers through profiling traces and tickets: hydration cost, bundle size, image components, font loading and caching headers.
How long it takes and what affects scope
The diagnosis and first round of fixes on a typical small business WordPress site usually take one to two weeks. Larger or custom sites take longer, especially if changes go through a developer release cycle. Lab scores change immediately; Search Console field data typically needs around four weeks after the fix to reflect it, because of the 28-day window, and low-traffic sites may not have enough field data at all.
What affects scope, without quoting prices here:
- Number of distinct templates that fail, not total page count.
- Platform and how much control you have over the server.
- Whether hosting needs changing, which I can advise on and help migrate.
- How many third-party scripts the business insists on keeping.
- Whether I implement or brief your developer.
Mistakes I see on slow sites
- Stacking two or three optimisation plugins that minify and combine the same files, which breaks layouts or makes things slower.
- Lazy-loading the hero image, which delays LCP on every page.
- Chasing a 100 lab score while field data, which is what Google uses, still fails.
- Testing only on a fast office connection and desktop, when most visitors arrive on mid-range phones over mobile data.
- Adding every marketing tag directly to the theme and again through Tag Manager.
- Uploading 4 MB phone photos and relying on the browser to resize them.
If a site is so slow that the theme itself is the problem, a rebuild may be cheaper than patching. In that case my SEO web design and development service builds a lightweight site with speed budgets from day one.
What I deliver
- A Core Web Vitals report by template and device, based on your field data.
- A diagnosis naming the LCP element, the main INP offenders and every significant layout shift source.
- Implemented fixes on staging and live, or developer tickets with exact changes.
- Image, caching, CDN and font configuration where relevant.
- A third-party script audit with recommendations on what to remove, delay or keep.
- Before and after measurements, and a regression checklist for your team.
Frequently asked questions
Is a speed plugin enough on its own?
Rarely. Caching and minification plugins help, but they cannot fix a bloated theme, oversized images, heavy third-party scripts or slow hosting. They soften the symptoms. I often keep one well-configured plugin and remove the rest.
Why does PageSpeed Insights show a good score but Search Console still says Poor?
The score is a single lab test on a simulated device. Search Console uses real visits over 28 days at the 75th percentile. Slow real devices, slow networks, logged-in states and third-party scripts that load late all show up in field data but not always in the lab.
Will faster Core Web Vitals improve my rankings?
Core Web Vitals are part of Google’s page experience signals, but relevance and content quality still matter far more. Where two pages are close, speed can help, and it reliably helps conversions and bounce. I will not promise ranking jumps from speed alone.
Do I need to change my hosting?
Not always. If server response time is consistently slow under normal traffic, yes. If the server is fast and the page is heavy, new hosting will not fix it. I check this before recommending any move.
Can you fix speed without changing how my site looks?
Usually, yes. Most gains come from how assets load rather than what the visitor sees. Where a design element such as a large video slider is the main problem, I explain the trade-off and let you decide.
How do you measure success?
By the share of URLs passing Core Web Vitals in Search Console and the field values for LCP, INP and CLS on your key templates, compared with the baseline I record before starting.
If your site is failing Core Web Vitals or simply feels slow, request a free speed review and I will tell you which template and which metric to fix first.
Request received
Thank you! Saad will contact you within the next 24 hours.
Keep an eye on your phone and inbox.