Making the site fast at the level where speed is decided
Speed optimisation is engineering work on why a site is slow: how much JavaScript ships, how the page renders, what is cached and where, how many database queries a page makes, and whether the hosting can serve the traffic. It is a different discipline from tuning three specific metrics for a search engine.
There are two conversations about website speed that get conflated. One is about passing Google's assessment, which concerns three specific measurements. The other is about the site actually being fast, which is an engineering problem with causes further down the stack. This page is about the second one. Fixing it usually resolves the first as a consequence.
Slow sites are slow for structural reasons that image compression does not touch. A JavaScript bundle that grew feature by feature until the browser spends a second parsing it before anything is interactive. Pages assembled at request time with no caching, so every visitor triggers the same work. Database queries that were fine with 200 records and are not fine with 200,000. Shared hosting that was adequate at launch. And a rendering approach that makes the browser do work the server could have done once.
When this work makes sense
Questions worth asking any supplier
Is the diagnosis at the right layer? Compressing images on a site slowed by database queries changes nothing.
How much JavaScript ships, and how much is used? Unused code is the most common single cause.
Is anything cached? Uncached page assembly repeats the same work for every visitor.
Has the hosting been reviewed since launch? Traffic and data both grow; shared hosting does not.
Will the improvement survive the next feature? Without a budget, speed regresses with every release.
Deliverables
Profiling to establish where time is actually spent, network, server, parse, render or database
JavaScript bundle analysis, with unused and duplicated code removed
Rendering strategy review: static generation, server rendering or client, chosen per page type
Caching at the layers that apply, CDN, server, application and database
Database query analysis and indexing where queries are the bottleneck
Image and font pipeline producing correctly sized modern formats at build time
Hosting assessment against actual traffic and data volume
A performance budget enforced in the build, so regressions fail rather than accumulate
Built with
Process
Speed work begins with profiling rather than with a checklist, because the common optimisations are frequently irrelevant to the actual cause. A site can be slow in the network, in server response, in JavaScript parsing, in rendering or in the database, and each has a different fix. We measure which before touching anything. Applying the standard list to a site whose bottleneck is a missing database index produces a faster-loading page that is still slow to use.
The standard nine stages, discovery, strategy, UX/UI, development, content and SEO, testing, launch, measurement and continuous improvement, apply to every project. The paragraph above is what differs for this one.
What moves the number
Pricing depends on scope, functionality, integrations and content requirements. These are the factors that change it most:
Configuration, code work, or architectural change
Configuration and assets
Fits: Sites slowed by images, fonts and missing caching
Limits: Bounded. Will not fix a heavy bundle or a slow database
Code and query optimisation
Fits: Applications where server time or JavaScript weight dominates
Limits: Needs development access and regression testing
Rendering architecture change
Fits: Client-rendered sites that are structurally slow to become interactive
Limits: Effectively rebuilding how pages are produced
Case studies
No published speed optimisation case study. Before and after scores from a lab test are easy to produce and prove little about real-world performance.
MBGDesk operates from 4 offices in India, United States, United Kingdom, United Arab Emirates. We hold no industry certifications and do not imply otherwise.
Frequently asked questions
How is this different from Core Web Vitals work?
Core Web Vitals optimisation targets three specific measurements Google uses as a ranking signal, against field data. This is the engineering underneath, bundle size, caching, queries, hosting. They overlap, and fixing the engineering usually fixes the metrics. Starting from the metrics can lead to tuning numbers without the site becoming meaningfully faster.
Our site was fast at launch and is slow now.
Almost always accumulation, features, scripts, plugins and data volume added over years, each individually small. Profiling shows which of those actually costs time, which is rarely the one people suspect.
Will a better hosting plan fix it?
Sometimes, and it is the most oversold answer in this area. If the server is genuinely saturated, more resources help. If the site ships two megabytes of JavaScript, a faster server delivers it marginally sooner and the browser still has to parse it.
How much JavaScript is too much?
Less than most sites ship. The practical test is how much of what you send is actually used on the page it loads on, bundle analysis usually shows a substantial proportion is not, often from a library included for one feature.
Can you speed up WordPress?
Usually and substantially, mostly through caching, reducing plugin load and fixing queries. The limit is that some themes and page builders generate heavy output by design, and there is a floor below which you cannot go without changing them.
How do we stop it getting slow again?
A performance budget enforced in the build, the build fails if the bundle exceeds an agreed size. Without that, speed erodes one feature at a time and nobody can identify which change caused it.
Services that connect to this
Talk to us about this
Tell us what you are trying to build and we will come back with scope, approach and an estimate.