Measured before touched
The site is profiled first and the baseline recorded, so the improvement is a fact you can check rather than a claim I make.
Freelance WordPress Speed Optimisation Expert in Bangalore
Measured first, then fixed at the cause — not another cache plugin.
Slow WordPress usually comes down to one or two specific things, and they are rarely what people guess. I profile the site, find what is actually costing the time, fix that, and show you the numbers before and after.
- Profiled before anything is changed
- Before and after numbers, shared
- Field data, not just lab scores
- Replies within one working day
Overview
Why WordPress sites get slow.
Almost every slow WordPress site is slow for one of five reasons: too many plugins running code on every request, images shipped at far larger dimensions than they are displayed, no caching or caching that is misconfigured, a database carrying years of accumulated cruft, or hosting that cannot keep up. Usually it is two of those, and usually one of them accounts for most of the delay.
What makes this hard to fix by guessing is that the obvious suspect is often innocent. A site can have thirty plugins and be fine, or six and be slow because one of them queries the database on every page load. A cache plugin can make a brochure site fly and break a WooCommerce cart. The only way to know is to measure the specific site.
Speed matters for two separate reasons, and they are worth keeping apart. The commercial one is that people leave – a slow site loses visitors before they see anything, and on a store that is money. The technical one is that Core Web Vitals are part of how Google assesses page experience, so performance is part of the search picture too.
Core Web Vitals are three specific measurements: Largest Contentful Paint, how long until the main content appears, where Google’s published threshold for "good" is 2.5 seconds; Interaction to Next Paint, how quickly the page responds when someone taps something, with a threshold of 200 milliseconds; and Cumulative Layout Shift, how much the page jumps about while loading, with a threshold of 0.1.
The important distinction is between lab data – a synthetic test from a tool – and field data, which is what real visitors on real devices actually experienced. A perfect score in a testing tool means very little if your customers are on mid-range phones on a patchy connection. The field numbers are the ones that count.
What I offer
Speed work Icarry out
01
Performance audit & profiling
Profiling the site to find which queries, plugins, scripts and assets actually consume the time, rather than reading a score and guessing.
You spend money on the thing that is slow, instead of on everything that might be.
02
Core Web Vitals work
Targeted work on LCP, INP and CLS, using field data from real visitors alongside lab testing.
Improvement measured the way Google measures it, not the way a test tool reports it.
03
Image optimisation
Images resized to what they are actually displayed at, compressed, converted to WebP, and lazy-loaded below the fold.
Usually the single largest saving on a content-heavy site, and the least risky to make.
04
Caching & delivery
Page, object and browser caching configured properly, with a CDN where it earns its place, and cart and session pages correctly excluded.
Repeat visits get much faster without a logged-in user ever seeing someone else’s cart.
05
Database optimisation
Clearing accumulated revisions, expired transients and orphaned metadata, and adding indexes where queries need them.
Sites that have grown slower every year usually get a noticeable step back here.
06
Plugin & script audit
Finding what each plugin costs per request, removing what is redundant, and deferring scripts that do not need to block rendering.
Less code running on every page view, which is the saving that does not degrade over time.
07
Hosting review & migration
An honest assessment of whether the server is the limit, and a move to something adequate if it is.
No more paying to optimise around hosting that was never going to be enough.
08
WooCommerce performance
Cart fragments, product queries, faceted filtering and large catalogues – the parts of a store that do not respond to ordinary caching.
Category and product pages that stay quick as the catalogue grows.
Key benefits
How the work is done.
The method matters more than the tool list.
Real-visitor data
Field data from actual devices is weighted above lab scores, because your customers are not running the test from a data centre.
Changed on staging
Performance work touches caching, scripts and queries – exactly the things that break checkouts. It is tested on a copy first.
One change at a time
Changes are applied and measured individually where it matters, so if something regresses it is obvious which change did it.
Mobile is the target
Optimised for a mid-range phone on an ordinary connection, which is what most of your traffic actually is.
Before and after, shared
You get the numbers from both ends, from tools you can run yourself, not a screenshot of a score I chose.
Nothing broken quietly
Forms, carts, logins and anything interactive are re-tested after the work, because aggressive optimisation is very good at breaking them.
Written up
What was changed and why, so the next person to touch the site does not undo it by accident.
Made to last
Where the cause is a habit – uploading 4000px images, say – the fix includes stopping it happening again.
Who this is for
Who needs speed work.
Usually it is obvious. Sometimes it shows up as something else entirely.
Sites failing Core Web Vitals
Search Console is reporting URLs as needing improvement or poor, and nobody is sure which part to attack first.
Stores losing people at the cart
Analytics shows a drop-off that is not about price or product, and the cart page takes six seconds on a phone.
Sites that got slower over time
It was fine at launch. Three years of content, plugins and images later, it is not, and no single change caused it.
Image-heavy sites
Portfolios, property listings, galleries and catalogues, where the photographs are the point and also the problem.
Sites on shared hosting
Where the question is genuinely whether optimisation will be enough or the hosting has simply been outgrown.
Sites built with page builders
Elementor, Divi or WPBakery builds carrying a lot of markup and script, where there is usually a great deal to reclaim.
Businesses buying traffic
Where a slow landing page is wasting ad spend on visitors who leave before the page appears.
Sites with mobile problems only
Fine on a laptop, poor on a phone – which is the pattern that matters most and gets noticed least.
Agencies with a client complaint
A performance problem on a site you built, where a second opinion is faster than arguing about it internally.
Where I work
Speed optimisation from Bangalore.
I work with businesses in Bangalore and across India, and Indian traffic conditions are worth designing for specifically. A large share of visitors arrive on mid-range Android phones over mobile data that is fast in the city centre and much less so elsewhere. A site tuned on office fibre and a recent iPhone can feel completely different in the hands of the people actually buying from you.
That changes what to optimise. Payload size matters more than it does on a market where most traffic is on broadband, because every kilobyte is paid for on a metered connection. Time to interactive matters more than a first paint that looks fast but does nothing when tapped. And server location genuinely matters – a site hosted in the US serving mostly Indian visitors is paying a round-trip penalty on every request.
The work itself is entirely remote, and the measurements are the deliverable: a baseline, the changes made, and the numbers afterwards from tools you can run yourself. That is the same for clients in the UK, USA, Canada, the UAE and Singapore, where the field conditions differ but the method does not.
Tuned for mobile data
Optimised for mid-range Android on ordinary connections.
Server location
Hosting geography reviewed against where your visitors are.
Field data first
Real-visitor numbers weighted above synthetic lab scores.
Clients overseas
India, the UK, USA, Canada, the UAE and Singapore.
Serving Chennai, Bangalore, India, Canada, UK, USA, Dubai, Singapore.
Industries
Where speed pays.
The cost of a slow page is different in every sector.
E-commerce
Typically needs: Category and product pages that stay quick at scale, and a cart that cannot be cached the ordinary way.
How I help: Query and index work on product listings, cart-aware caching, and image pipelines built for a catalogue that keeps growing.
News & publishing
Typically needs: High article volume, heavy advertising scripts and readers arriving from social on phones.
How I help: Third-party script auditing and deferral, article template optimisation, and layout shift eliminated from ad slots.
Real estate
Typically needs: Listing pages carrying dozens of large photographs and map embeds.
How I help: Responsive image pipelines, deferred map loading, and gallery loading that does not block the first paint.
Travel & hospitality
Typically needs: Image-led pages with booking widgets loaded from a third party.
How I help: Hero image optimisation, third-party widget loading deferred, and layout reserved so the page does not jump.
Education
Typically needs: Traffic spikes at admissions time on pages carrying a lot of information.
How I help: Caching sized for the spike, plus template work so heavy listing pages hold up under it.
Professional services
Typically needs: Modest traffic but high-value visitors who will not wait.
How I help: Straightforward wins – images, caching, unused plugins – usually enough without a rebuild.
Healthcare
Typically needs: Information people look for urgently, often on a phone.
How I help: Fast first paint on the pages that matter most, with appointment and contact paths prioritised.
Portfolios & creative
Typically needs: Large images and animation, where quality cannot simply be traded away.
How I help: Modern formats and careful sizing that keep the imagery looking right while cutting the weight.
Sites running paid ads
Typically needs: Landing pages where slow loading is money spent on visitors who never arrive.
How I help: Landing page work targeted at the pages the spend actually points at.
How I work
How an optimisation runs.
Six stages, starting and ending with a measurement.
Discovery
I gather the field data from real visitors and run lab profiling myself, then look at what is actually happening: server response time, database queries, plugin load, assets and third-party scripts.
Planning
I set out what to change, in what order, with the expected gain and the risk of each. Anything that could affect carts, forms or logins is flagged before it is touched.
Design
The quick structural wins: images resized and converted, unused plugins and themes removed, render-blocking assets deferred, fonts trimmed to what is used.
Development
The deeper work: caching configured with the right exclusions, database cleaned and indexed, slow queries addressed, CDN set up where it helps, and hosting changed if it is the limit.
Testing & SEO
Everything re-tested: forms, carts, checkout, logins, search and anything interactive, across devices and browsers, then the performance re-measured.
Launch & support
A written report comparing before and after on both field and lab data, what was changed, and what to avoid doing in future to keep it.
Technology
What I measure with.
Several tools, because each one shows a different part of the picture.
Measurement
Core Web Vitals field dataWhat real visitors experienced, which is the data that counts.
Lighthouse & PageSpeed InsightsLab profiling for reproducible before-and-after comparison.
WebPageTestWaterfall analysis from chosen locations and connection speeds.
Query MonitorWhich queries, hooks and plugins are consuming the request inside WordPress.
Delivery
Page & object cachingConfigured with correct exclusions for carts, sessions and logged-in users.
CDNWhere the audience is geographically spread enough for it to earn its cost.
WebP & responsive imagesModern formats at the size each breakpoint actually displays.
HTTP/2, compression, preloadTransport-level settings that cost nothing and are often simply not switched on.
Underneath
MySQLQuery analysis, indexing and clearing the metadata that accumulates over years.
PHPRunning a current version with OPcache configured, and fixing the code that is slow.
Hosting & server configReviewing whether the server is the ceiling before optimising around it.
Features
What typically gets changed.
Selected from the audit — not applied wholesale because a checklist said so.
Image resizingServing images at display size instead of camera size.
WebP conversionModern formats with fallbacks, usually the largest saving.
Lazy loadingBelow-the-fold images and iframes deferred until needed.
Script deferralNon-critical JavaScript moved out of the render path.
CSS reductionUnused styles removed, critical CSS inlined where it helps.
Font subsettingOnly the weights and characters actually used are loaded.
Page cachingConfigured with correct exclusions for dynamic pages.
Object cachingRepeat database results held in memory between requests.
Database cleanupRevisions, transients and orphaned metadata cleared.
Query optimisationSlow queries indexed or rewritten at the source.
Plugin reductionRedundant and abandoned plugins removed, not just disabled.
Layout stabilityDimensions reserved so the page stops jumping while it loads.
SEO & performance
Speed is part of page experience.
Core Web Vitals form part of how Google assesses page experience, so performance and SEO overlap. They are not the whole picture – relevant content still matters far more – but a slow site is a handicap you are carrying for no reason.
To be plain: no one can guarantee a ranking, and improving your vitals will not by itself move you up the page. What it does is remove a known negative and stop you losing visitors who would otherwise have stayed.
- LCP, INP and CLS measured against Google’s published thresholds
- Field data from Search Console treated as the source of truth
- Mobile performance prioritised over desktop scores
- Layout shift eliminated rather than reduced
- Render-blocking resources identified and dealt with individually
- Server response time addressed before front-end tuning
- Third-party scripts audited for what they actually cost
- Image formats and sizing handled at the pipeline, not per page
- Improvements confirmed in the field weeks after the work
- Findings written up so the gains are not undone later
AI search
Fast pages are easier to use.
Performance work is not an AI-search tactic, and it would be dishonest to sell it as one. What is true is that the things which make a page fast – clean markup, less script, content present in the HTML rather than assembled afterwards – also make it easier for anything automated to read.
Nobody can promise inclusion in any AI answer engine. A page whose content exists in the source rather than appearing after three seconds of JavaScript is simply easier for everything to read, people included.
- Content present in the HTML, not assembled by script
- Semantic markup that survives aggressive optimisation
- Structured data preserved through minification
- Text readable without waiting for fonts to download
- Fewer third-party scripts obscuring the actual content
- Consistent markup across templates
- Accessible pages, which tend to be machine-readable pages
- Quick server responses for anything crawling the site
Why me
Why bring it to me.
The practical reasons, rather than the adjectives.
I profile before I touch anything
The audit comes first and names specific causes with what each one costs. If the honest answer is that your hosting is the ceiling, you get told that rather than sold three months of tuning around it.
Field data over test scores
A green score in a testing tool means very little if your customers are on mid-range phones. The numbers that decide whether the work succeeded are the ones from real visitors.
I know what optimisation breaks
Aggressive caching and script deferral are excellent at breaking carts, forms and logins. Twelve years of building the things being optimised means knowing where to look afterwards.
You get the numbers
Before and after, from tools you can run yourself. No screenshot of a score I picked, and no claim you cannot verify independently.
I will tell you when it is a rebuild
Sometimes a site is slow because of how it was built, and no amount of optimisation fixes that economically. Saying so costs me the work and saves you the money.
The gains are written down
What changed, why, and what not to do afterwards – because performance usually regresses when the next person does not know which decisions mattered.
FAQ
Speed questions.
Almost always one or two of five things: too many plugins running code on every request, images far larger than they are displayed, missing or misconfigured caching, a database carrying years of accumulated data, or hosting that has been outgrown. Which of those applies to your site can only be established by profiling it – guessing is how people end up with three caching plugins and no improvement.
Three measurements Google publishes thresholds for. Largest Contentful Paint is how long until the main content appears, with 2.5 seconds as good. Interaction to Next Paint is how quickly the page responds when tapped, with 200 milliseconds as good. Cumulative Layout Shift is how much the page moves while loading, with 0.1 as good. They are measured from real visitors, not from a test.
It depends entirely on what the audit finds. Resizing images and removing redundant plugins is a small job. Rewriting slow queries, restructuring a page-builder site or migrating hosting is a larger one. I audit first, tell you what each fix would cost and what it should gain, and you decide how far to go. The quote comes after the audit, not before.
The audit takes a day or two. The work itself is usually one to two weeks, depending on how much of it you choose to do and whether hosting is changing. Field data then takes a few weeks to catch up, because Core Web Vitals are measured over a rolling window of real visits – so the confirmed improvement arrives after the work does.
Sometimes, partly. Caching helps a great deal with repeat visits to static pages and does nothing at all for a cart, a checkout or a logged-in user. If the underlying problem is oversized images or a slow query, caching hides it from some visitors rather than fixing it. It is one tool among several, not the answer on its own.
Yes, and stores need a different approach. Cart and checkout pages cannot be cached the ordinary way, cart fragments make requests on every page load, and product filtering generates queries that get slower as the catalogue grows. Those need query and index work rather than caching, which is why generic speed services often disappoint on stores.
It can, which is exactly why the work is done on a staging copy and everything interactive is re-tested afterwards. Script deferral and aggressive caching are very good at breaking forms, carts and logins in ways that are not visible on the homepage. Nothing goes live until the site has been exercised properly on staging.
It might be, and the audit will say so plainly if it is. A server that takes 1.5 seconds to produce the HTML puts a floor under everything else, and no amount of front-end optimisation gets below it. If that is the case I will tell you, recommend what would be adequate, and handle the migration if you want it done.
Only if your visitors are geographically spread. If nearly all your traffic is in India and your server is in India, a CDN adds cost and complexity for a marginal gain. If you serve visitors across several countries, it helps considerably. The audit includes where your traffic actually comes from, so the decision is made on your data.
It removes a known negative rather than adding a positive. Core Web Vitals are part of how Google assesses page experience, so failing them is a handicap. Passing them does not by itself move you up the results – relevance and content matter far more. Anyone promising a ranking improvement from speed work alone is overselling it.
Yes. Page-builder sites carry a lot of markup and script by design, which usually means there is a great deal to reclaim – but also that some of the weight is structural and cannot be removed without rebuilding. I will tell you how far optimisation can take it, and what the ceiling is if you stay on the builder.
You get the before and after from both lab tools and field data, using tools you can run yourself – PageSpeed Insights and Search Console are free and independent of me. The field numbers take a few weeks to update after the changes go live, so the final comparison comes a little after the work is done.