Core Web Vitals are a measurement. So the work starts with one.

Enhanced speed and responsiveness for better SEO and user experience, asset budgets, font strategy and render-path cleanup.

Speed is not a badge. It is the difference between a visitor arriving and a visitor leaving, and it is the one part of a website that can be argued about with a number instead of an opinion.

The four numbers every build is held to

Lighthouse
99/100
performance, a11y, best practices
LCP
0.9s
target is under 2.5s
CLS
0.00
zero layout shift
Uptime
99.9%
monitored, alerted, resolved

The standard a build is held to before it is allowed to go live, and the standard an optimization engagement is measured against afterwards. LCP target is under 2.5s.

What actually moves the numbers

Every one of these is a specific thing on a specific page, with a specific fix. If a proposal talks about speed without naming which element is the LCP element, it has not looked at your site.

0.9s

What actually moves LCP

Largest Contentful Paint is one element, almost always the hero image, or the headline block behind it. Every fix below is about that element arriving sooner, and nothing else on the page is allowed to get in front of it.

  1. The hero image is the LCP element, and nothing tells the browser that

    The fixRight-sized responsive sources so a phone never downloads the desktop file, eager decoding and a high fetch priority on that one image, and lazy-loading kept strictly below the fold.

  2. The LCP image is a CSS background, so it is discovered late

    The fixMoved into markup where the preload scanner can see it before the stylesheet has even finished parsing. This is often the single largest change on the page.

  3. Render-blocking work sits in front of the first paint

    The fixEverything that has to be fetched and executed before anything can draw gets cut, deferred or moved. What is left in the critical path is only what the first screen genuinely needs.

  4. Webfonts hold the text hostage

    The fixFamilies and weights reduced to what the design actually uses, the connection opened early, and a display strategy that paints text immediately rather than leaving a blank block.

  5. Third-party tags load first and matter last

    The fixChat widgets, tag managers and pixels moved behind the first paint or behind an interaction. They rarely have to be there for the hero to draw, and they usually are.

0.00

What actually moves CLS

Cumulative Layout Shift is not a speed problem, it is a reservation problem. Every shift is something that arrived late and pushed what was already drawn. The fix is always the same: reserve the space before the thing exists.

  1. Images and embeds ship without dimensions

    The fixExplicit width and height, or an aspect ratio, on every image, video and iframe, so the box exists at parse time and the picture drops into a space that was already there.

  2. The webfont swaps and moves every line with it

    The fixA fallback matched to the webfont metrics so the swap costs no reflow, and the families kept few enough that the swap happens once rather than four times.

  3. Something is injected above content that is already drawn

    The fixAnnouncement bars, cookie notices and consent layers given reserved space or moved out of the flow entirely, instead of pushing the whole page down when they arrive.

  4. Motion animates layout instead of transform

    The fixOnly transform, opacity, clip-path and filter are ever animated. A reveal that animates height or margin repaints the layout and charges you for it on this metric.

  5. Late embeds resize themselves

    The fixMaps, forms and third-party widgets boxed at a fixed ratio so the frame cannot grow into the paragraph underneath it after the fact.

Three levers, pulled in this order

Asset budget, font strategy, render path. Everything else in performance work is a detail hanging off one of the three.

Asset budget

A ceiling agreed per template before the design is signed off, so speed is a design constraint rather than a clean-up task afterwards.

  • A weight ceiling per page type, agreed in writing, that the build is held to
  • Every image exported at the size it is actually displayed at, in a modern format
  • One hero image, not a five-frame slideshow nobody scrolls past
  • Anything that breaks the budget gets named as a trade-off and decided, not smuggled in

Font strategy

Type is the most expensive thing on most sites and the least examined. It is decided as a strategy, not inherited from a mood board.

  • Families and weights cut to the ones the design measurably uses
  • Variable faces where they replace three static weights with one file
  • The connection opened early, and the first-screen faces prioritised
  • A display strategy that never leaves invisible text waiting for a download

Render path

The order the browser is asked to do things in. Most slow sites are not heavy. They are badly sequenced.

  • What blocks the first paint identified and reduced to what the first screen needs
  • Script deferred, split, or removed where CSS already does the job
  • Third parties moved behind the paint or behind an interaction
  • The result measured on a phone-class device, not on the machine that built it

The one build where performance was in scope

Not the whole portfolio. Jobe's Hats is the build whose scope named performance, so it is the only one this page claims. The figures are the client's own reported change after launch.

Jobe's Hats

E-commerce 2024

Faster product pages, cleaner collection logic, and a checkout path with nothing in the way.

+50%
sales
+40%
revenue
  • E-commerce build
  • Performance
  • Collection logic
jobeshats.com
Jobe's Hats homepage built by Devdwell, a full-bleed western hero with outlined lime display type set over hat photography and a Buy hats action
A full-bleed photographic hero is the LCP element on a page like this one. It is the first thing budgeted and the first thing prioritised, everything else on the first screen waits behind it.
Jobe's Hats on a phone, the western hero and the Buy hats action stacked to one column above the fold
The phone is where the budget is set, because it is the device with the smaller pipe and the slower processor. A build that is fast here is fast everywhere.

Measure, budget, fix, measure again

Four beats, and the fourth returns to the first. That is not a diagram flourish. A site gets slower every time someone adds something, which is why the last beat is a habit.

  1. Measure first

    The live pages, on a phone-class device, before a single change. Which element is the LCP element, what is blocking it, and where the shifts are actually coming from.

  2. Agree the budget

    A ceiling per template and an explicit list of trade-offs. The ones that touch the design are decided with you rather than made quietly on your behalf.

  3. Fix in order of cost

    The LCP element, then the blocking work in front of it, then fonts, then third parties. Biggest lever first, so the numbers move before the invoice does.

  4. Re-measure, then keep measuring

    On live pages after the change, and again once real traffic has run through them. A number that was true on launch day is not a number that stays true.

The fourth beat is what a support retainer exists to keep doing, the numbers re-checked on live pages every month rather than once at launch.

$2,000

flat packages from, optimization is quoted the same way

An engagement on a live site is measured, scoped and quoted flat before it starts, so you are buying a defined body of work rather than an open meter. What moves the figure is how many templates there are and how much of the weight is third-party.

Three things speed work will not do for you

Stated here rather than discovered later. A performance page that only lists wins is a performance page that has not run this work on a real site.

  • A lab score is not a field score

    Lighthouse runs one page on one simulated connection. Real users arrive on real networks with real devices, and that is the number worth optimising for, which is why the work is re-measured against live traffic rather than declared on the day it ships.

  • Some weight is the business, not the build

    A consent layer, an analytics stack, a chat widget your sales team lives in. These cost something. What we control is when they load and what they are allowed to block, not whether you are allowed to have them.

  • Speed cannot rescue the wrong page

    A page that arrives in under a second and still does not say what you sell has a different problem. Performance work makes a good page competitive; it does not make a bad one convert.

Questions asked before the first measurement

Anything not answered here gets a reply within one business day.

Can you optimize a site we already have?

Yes. That is the usual shape of this engagement. It starts from a measurement of your live pages rather than from a template of recommendations, and the findings come back as an ordered list with the biggest lever at the top.

Our Lighthouse score is fine, so why does the site feel slow?

Because a lab score is a simulation of one page on one connection. Field data from real devices on real networks is the honest measure, and the two disagree most often when third-party scripts or fonts are involved.

Will making it faster change how it looks?

Only where you agree to it. Where speed and a design decision genuinely conflict (a fifth webfont weight, an autoplaying background video) the trade is named and you decide it. Nothing is quietly removed to make a number look better.

Is performance work part of a build, or separate?

Every custom build carries a performance pass before launch, held to the same four numbers on this page. This engagement is the deeper version on a live site: measurement, an asset budget, font strategy and render-path work across every template.

How long does a Webflow build take?

Most projects run four to eight weeks end to end, across discovery, design, build, QA and launch. Timelines hold because the sequence is the same every time.

What does a project cost?

Flat, transparent packages starting at $2,000. You get the figure before work starts, so there is a budget you can plan around rather than an hourly estimate that drifts.

Will moving from WordPress to Webflow hurt our search rankings?

No. Migrations include a full redirect map and parity checks, so every ranking is preserved while the site gains speed and a CMS your marketing team can actually use.

Can our team update the site without a developer?

Yes. Every launch includes hands-on one-to-one CMS training, and the build is structured with clean, semantic components your team can extend on their own.

What happens after launch?

Ongoing maintenance, uptime monitoring and dedicated troubleshooting on a retainer. Issues get resolved, not logged and forgotten.

Send the URL. We will send back the measurement.

Design that converts, speed that scales. Real pages, on a phone-class device, with the LCP element named and the findings ordered by how much each one is costing you.

Lighthouse
99/100
LCP
0.9s
CLS
0.00
Packages from
$2,000