**[ Performance · Sprint ]**Website speed optimization services

# Speed work measured by real visitors, not one lab score.

A fixed two-to-four-week sprint on your WordPress, WooCommerce, Shopify or Laravel site. We find what slows LCP, INP and CLS, fix it in priority order, and measure the result the same way we measured the baseline.

[Scope a speed sprint](https://w3experts.com/start-a-project/)[Try the free speed check](https://w3experts.com/tools/core-web-vitals-checker/)

Format**Fixed sprint**

Timeline**2-4 weeks**

Platforms**WordPress · WooCommerce · Shopify · Laravel**

Measured in**CrUX field data plus lab traces**

Not promised**A perfect Lighthouse score**

Ownership**You own the files and accounts**

Fit and scope

## Is a speed sprint the right project?

### Good fit if

- Your Core Web Vitals fail in Search Console or the CrUX report
- Pages feel slow on phones even though the desktop score looks fine
- A theme, app or plugin change made the site slower and nobody knows which
- You want fixes you can keep, with the before and after method written down

### Not a fit if

- You want a guaranteed score or a ranking promise
- You cannot give us staging or admin access to test changes safely
- The site needs a rebuild more than a tune-up
- You need field-data proof on a site with too few visitors for CrUX to report

[02] Speed sprint

## Speed optimization, measured where it counts.

A fixed sprint on your existing site. We fix what moves the field numbers: images, fonts, scripts, apps and plugins, caching and server response. Then we compare field data and lab traces taken under the same conditions.

- Baseline report with field and lab data
- Fixes ranked by impact per hour
- Before and after under identical conditions

[Scope a speed sprint](https://w3experts.com/start-a-project/)

Scope by area

## What a speed sprint covers.

Each area is marked included, excluded or optional in the proposal.

01

### Baseline

CrUX field data for your origin and key URLs, plus lab traces on the templates that matter: home, product, category, post and checkout.

02

### Images and media

Formats, sizes and lazy loading, with the LCP image loaded first. Video and embeds load only when needed.

03

### Fonts

Self-hosted files, fewer weights, preloads and fallback faces sized so text does not jump when the font swaps.

04

### Third-party scripts

Tag managers, chat, reviews, pixels and test tools listed with their cost, then delayed, trimmed or removed with your sign-off.

05

### Theme, apps and plugins

What each one loads on each template. We remove or replace the heavy ones and record why.

06

### Interaction (INP)

Long tasks traced in Chrome, heavy event handlers split up, and main-thread work cut on the pages people click most.

07

### Caching and server

Page and object caching, CDN rules and server response time checked. Hosting changes are recommended, never forced.

08

### Layout stability (CLS)

Space reserved for images, banners, ads and embeds, so content stays put while the page loads.

Inspectable artifact

## A speed findings ledger, as we deliver it.

A sample with illustrative findings. Yours lists your templates, your numbers and the test conditions.

**speed-findings · sample-store · mobile**6 findings · ranked by impactIllustrative artifact

| # | Finding | Evidence | Fix | Status |
| --- | --- | --- | --- | --- |
| F-01 | Hero image loads late on product pages | Lab trace: LCP image requested after two scripts | Preload, correct size, AVIF and WebP | Fixed |
| F-02 | Review widget blocks the main thread | Long tasks after tapping add to cart | Load the widget when it scrolls into view | Fixed |
| F-03 | Four font weights, no fallback sizing | Layout shift when the font swaps on mobile | Two weights, size-adjusted fallback | Fixed |
| F-04 | Chat script on every page | Third-party bytes in the waterfall | Load on interaction, product pages only | Approved |
| F-05 | Removed app still injects code | Theme code search and network log | Remove leftover snippets | Fixed |
| F-06 | Slow server response on cart | Server response time across five lab runs | Hosting change, recommended | Open |

How we measure

## Before and after, under the same conditions.

A speed claim is only as good as its method. These rules apply to every sprint.

### Field data

- CrUX at the 75th percentile, for the origin and key URLs, over a 28-day window.

### Lab traces

- Same device profile, network, location and URLs before and after. Several runs, median reported.

### Templates

- Every key template tested, not just the homepage.

### Interactions

- INP checked on real clicks: menus, filters, add to cart and forms.

### Third parties

- Each script measured with it on and off, so its cost is on record.

### Change log

- Every fix dated, so a shift in field data can be matched to a change.

### Time window

- Field data takes 28 days to fully reflect a change. We report the trend and book a check-in.

### Limits

- Sites with too little traffic for CrUX get lab evidence only, and the report says so.

What you get

## Deliverables you can open, not a score screenshot.

Everything stays in your accounts. You keep the reports and the change log.

Report

### Baseline report

Field and lab numbers for each key template, with the test conditions written down.

Ledger

### Findings ledger

Every issue with its evidence, fix, owner and status, ranked by impact per hour.

Code · Staging

### Fixes on staging first

Theme, plugin, app and server changes tested on staging, then released in a quiet window.

Report

### Before and after report

The same tests rerun under the same conditions, with field data tracked through the 28-day window.

Docs

### Keep-it-fast notes

Rules for images, fonts, scripts and new apps, so the gains survive the next change.

How it works

## Two to four weeks, measured at both ends.

Fixes go to staging first. Nothing reaches the live site without a test and a way back.

Days 1-3 · Baseline

### Measure and trace

Field data pulled, key templates traced in the lab, and scripts and apps listed with their cost. Output: the baseline report.

Baseline agreed

Admin, hosting and analytics access

Wk 1 · Plan

### Rank the findings

Each finding sized by impact and effort. You approve which scripts, apps and plugins can change.

Fix list approved

One review call

Wk 2-3 · Fix

### Fix on staging, release in batches

Fixes built and tested on staging, then released in small batches so each change can be measured.

Each batch accepted

Sign-off on visible changes

Wk 3-4 · Prove

### Re-test and hand over

Lab tests rerun under the baseline conditions, field trend tracked, keep-it-fast notes handed over, and a check-in booked after the 28-day window.

Before and after report delivered

Final review

## Check your Core Web Vitals.

**K02** Core Web Vitals report card

### Is your site fast for real visitors?

Not a Lighthouse score. The numbers Google actually uses: field data from Chrome users over the last 28 days, plus a lab run to explain them. With fixes in plain English, sorted by what moves the needle.

[Check your URL](https://w3experts.com/tools/core-web-vitals-checker/)

Adjacent

## Bigger, smaller or different?

Three doors next to this one.

[S14

### Website Maintenance and Care Plans

Updates on staging first, restore drills, monitoring, a monthly report.](https://w3experts.com/services/website-maintenance/)[S06

### Website Redesign

Keep the rankings and content that work. Replace what doesn't.](https://w3experts.com/services/website-redesign/)[S09

### Shopify Development Services

Stores that load fast, check out cleanly and reconcile every order after a migration.](https://w3experts.com/services/shopify-development/)

Questions

## Speed Optimization questions.

Do you guarantee a Lighthouse score or a Core Web Vitals pass?

It depends on who builds the templates. On a site we design and build, the launch guarantee applies. If a template we built misses Core Web Vitals at launch, we fix it at no cost. A speed sprint on an existing site guarantees the method, not a pass. You get a baseline, ranked fixes, and a before and after measured under the same conditions. Field data depends on your visitors' devices and networks, which no one controls.

What is the difference between field data and lab data?

Field data comes from real Chrome users and is collected in the CrUX report over 28 days. Lab data is a controlled test on one device and network. Google looks at field data, and lab traces explain why the field numbers look the way they do.

Which metrics do you work on?

The three Core Web Vitals: LCP for loading, INP for responsiveness and CLS for visual stability. We also track server response time and total script cost, because they drive the first two.

Can you speed up a Shopify store?

Yes, within the platform's limits. Shopify controls hosting and checkout, so the work focuses on the theme, apps, images, fonts and third-party scripts. Leftover code from apps you removed is a common find.

Do you work on WordPress, WooCommerce and Laravel sites?

Yes. On WordPress and WooCommerce we also tune plugins, caching, database queries and hosting. On Laravel we look at queries, caching, asset builds and server setup as well as the front end.

Will you remove our marketing scripts?

Not without your sign-off. We list every third-party script with what it costs and who uses it. You decide what stays, and we load the rest later or only on the pages that need it.

How long until we see results?

Lab results show up as soon as a fix ships. CrUX field data covers a rolling 28 days, so the full effect takes about a month to appear. We book a check-in after that window.

What if our site has too little traffic for field data?

CrUX only reports sites and pages with enough Chrome visitors. If yours does not qualify, we rely on lab traces under fixed conditions and say so plainly in the report.

Will a faster site improve our rankings?

Page experience is one of many ranking signals, so we don't promise ranking changes. A faster site is easier to use, especially on phones. Ongoing SEO campaigns are run by our sister agency BizAttic.

How do we keep the site fast afterward?

You get keep-it-fast notes for images, fonts, scripts and new apps or plugins. Under a monthly care plan, we run lab tests after every deploy and review field data each week.

Next step

## Send us the URL and the pages that matter most.

1. **01 · Today**Instant confirmation and a booking link.
2. **02 · 1 business day**An engineer replies with next steps.
3. **03 · 5 business days**Written, fixed-scope sprint proposal.
