Article
How to Improve Website Speed
A slow website does not feel premium. It feels broken. Visitors on mobile networks abandon forms; ads get more expensive; search systems use loading experience as one of many signals. Speed work is engineering, not a turbo plugin.
WEBCETRA Editorial · · · 11 min read
Measure first. Guessing leads to minifying things that were not the problem while a 4 MB hero video keeps running. Field data and lab data both matter; web.dev’s Vitals hub (https://web.devexplorevitals) explains the user-centric metrics. This article is the practical order of fixes for a business site.
Contents
- Measure before you rewrite CSS
- Images, video and fonts
- JavaScript: the usual suspect
- Hosting, caching and third parties
- Templates, CMS and page builders
- What not to do
- A 30-day speed backlog
- When speed needs a rebuild
Measure before you rewrite CSS
Use Chrome’s field data where available, PageSpeed Insights, and a filmstrip on a throttled mobile profile. Note LCP element, INP culprits and CLS sources. One number from a desktop test on office Wi-Fi will lie to you.
Test the templates that earn money: home, service, product, article. A blazing homepage and a 12-second product page is not a fast store. Pair this with blog/core web vitals explained so stakeholders know what the letters mean.
Images, video and fonts
Serve modern formats (WebP or AVIF) with sensible dimensions. Lazy-load below-the-fold images. Do not lazy-load the LCP image. Hero slideshows that load five full-width photos are a common self-inflicted wound.
Self-host a small font set; subset if you can. Avoid loading an entire icon library for two arrows. Replace autoplaying background video with a still unless the video is the product.
JavaScript: the usual suspect
Every slider, chat widget, animation library and tag manager container costs main-thread time. INP problems are often too much JS on tap. Remove unused plugins. Defer non-critical scripts. Do not inject three analytics tools that all fire on first paint.
If the site is a marketing page, you probably do not need a heavy client-side framework on every URL. If it is an application, code-split and treat the marketing pages differently. Custom app work is services/web app development; marketing sites are services/web development.
Hosting, caching and third parties
Shared hosting with no caching can make a well-built theme feel slow. Use HTTP/2 or HTTP/3, a CDN for static assets, and cache HTML where the page is public and not personalised. Authenticated pages need a different policy.
Third parties (maps, reviews, pixel packs, heatmaps) should load after interaction or on a delay. A review widget that shifts the footer is both a CLS and a trust problem.
Templates, CMS and page builders
Page builders often emit nested wrappers and unused CSS. A disciplined theme or a component-based front-end is easier to keep fast. WooCommerce and Shopify apps stack the same way — each app is a speed tax. See blog/woocommerce vs shopify.
Fix the template, not one page, when the issue is global (header, font, app). Fix the page when the issue is a particular embed or gallery.
What not to do
Do not install five optimisation plugins that minify, combine and cache in conflicting ways. Do not hostage the site to a single score-100 chase on a lab tool while field data is fine. Do not remove accessible labels to save bytes.
Do not pretend a CDN fixes unoptimised 6000-pixel PNGs. Do not delay security updates in the name of performance.
A 30-day speed backlog
Week 1: measure, inventory scripts, compress LCP media. Week 2: font and header cleanup, lazy-load policy. Week 3: remove or delay third parties, cache. Week 4: re-measure field and lab; document what you will not load again.
Keep a budget: for example, no new app without a before/after on mobile LCP. Speed regresses the same way features accrue — silently.
When speed needs a rebuild
If the theme cannot output reasonable HTML, if the builder locks you into 2 MB of JS, or if you need design that the canvas cannot produce without hacks, budget a rebuild. Cost context is in blog/how much does a business website cost.
Rebuilds should include a performance budget in the brief, not as a hope at the end. Technical SEO checklist items (crawl, HTTPS, redirects) should ship in the same project so you do not go live slow and unindexed.
Questions
Will a faster site make us rank first?
No. Speed is one factor and a conversion factor. A fast empty page still loses to a slower page that answers the query. Fix speed because users feel it.
Is a 100 PageSpeed score required?
No. It is a lab diagnostic. Aim for good field Core Web Vitals on key templates. Chasing 100 often means stripping features users wanted.
Can we fix speed without changing the design?
Often, yes: images, scripts, hosting, fonts. Sometimes the design itself (huge carousels, popups, webfont overload) is the bottleneck. Then design has to give a little.
Author
WEBCETRA Editorial. Practical articles from WEBCETRA on websites, SEO and digital systems. Written for business readers, not for ranking tricks.
Further reading on Google Search Central (developers.google.com/search/docs), Core Web Vitals on web.dev, and accessibility on the WCAG 2.2 quick reference.