Every few months a team decides its website is slow and concludes that the framework is to blame. A rebuild is approved, six months pass, and the new site launches at roughly the same speed as the old one. The cause was never the framework. It was a 4MB hero image, four font families and eleven marketing tags.
Core Web Vitals are not a score to chase for its own sake. They are a summary of how quickly a real person can see and use the page. The good news is that most of the damage is fixable without touching the application architecture.
Read the waterfall before the score
Open the network panel on a throttled connection and look at what loads first. The largest contentful element is often a hero image or a heading that waits for a web font. If the image alone takes two seconds, no amount of JavaScript optimisation will rescue the experience.
Run the test on a mid-range Android phone over a simulated 4G connection, not on a developer laptop on fibre. The gap between those two environments is where most performance budgets quietly fail.
Images: the highest-return fix
Serve images in AVIF or WebP at the size they are displayed, and let the browser choose with a srcset. A 1200-pixel image rendered in a 400-pixel card wastes bandwidth and delays the largest paint. Compression at quality 75 to 82 is usually indistinguishable on a phone screen.
Set explicit width and height attributes so the layout does not jump while the image loads. Reserve space for embeds and ads as well. Layout shift is often caused by the thing you forgot to measure, not the thing you optimised.
A rebuild is a six-month project with a new set of bugs. Compressing the hero image is an afternoon with a measurable result.
Fonts: fewer files, earlier discovery
Every font weight is a separate download. A site using three families across five weights can spend a second before the first paragraph is readable. Pick two weights, self-host the files, and preload only the one used in the first screen.
Use font-display: swap so text appears immediately in a fallback face, and check that the fallback metrics are close enough to avoid a visible jump. A variable font can replace several static files, but only if you actually need the range.
Key facts
- Largest Contentful Paint is usually an image or a web font.
- Third-party tags frequently cost more than the application code.
- Serve modern image formats at the size actually displayed.
- Self-host critical fonts and preload only the weights you use.
- Measure on a mid-range phone, not a developer laptop.
Third-party scripts are a budget line
Marketing tags, chat widgets, consent managers and analytics libraries all compete for the main thread. Each one looks small in isolation. Together they can add more blocking time than the site's own code. Audit them quarterly and remove anything that has not produced a decision in the last two quarters.
Load non-critical tags after interaction or on idle, and keep a hard cap on the total number. If a vendor cannot explain what its script does to the main thread, that is a reason to delay it, not a reason to trust it.
A realistic 30-day plan
Week one: compress and resize images, add dimensions, fix the hero. Week two: trim fonts and preload the critical face. Week three: defer or remove third-party tags. Week four: re-measure on the same device and connection, and record the before-and-after numbers.
Only after those four weeks should you consider a framework change. If the site is still slow, you will at least know why, and the rebuild will have a measurable target rather than a vague ambition.
The bottom line
Speed is usually an asset problem, not a code problem. Fix the images, fonts and tags first. Most sites recover a meaningful part of their performance in a month without a single line of application rewrite.
The Website & Web Development desk covers the build side. For how speed affects acquisition, read the Digital Marketing section.
