Standing service perf-keep-core-web-vitals-in-check · revised 11 October 2026
Standing service
Keep your key pages inside Core Web Vitals limits, month after month
We measure up to five named pages every month on a fixed test profile. When one slips past an agreed limit after a release, we find the cause and open a fix, or tell you what only you can change.
This starts a conversation by email. Nothing is charged, and nothing is measured, until we have agreed scope and terms with you in writing.
The responsibility you hand over
Page speed and layout stability are lost gradually: a new tracking script, a larger hero image, a late-loading embed or a font change can push a page past a limit without anyone noticing until a report or a customer says so. A one-off fix does not stop it happening again.
Who it’s for: A site or product owner, or an agency, whose important pages were once fast but slow down with each new script, image, embed or release, and who has nobody watching the numbers.
Usually starts when: A page was fixed once and has drifted back, a report shows pages moving from good to needs improvement, or releases are frequent and no one checks their effect on speed.
The result: Up to five named pages stay inside the agreed limits on a fixed lab test profile. Each month you see the figures for every page and, for any page that slipped, the cause and the fix pull request or the change only you can make.
What stays true, and what we do about it
No response-time guarantee is published for this new service. A target is agreed in writing before it starts, set to what a service at this stage can keep.
Hours are agreed in writing before the service starts. The service is not staffed round the clock and offers no out-of-hours cover.
What must remain true
- The named pages stay inside the agreed Core Web Vitals limits on the fixed lab profile
- Every slip past a limit is investigated and ends in a fix pull request or an explanation
What we watch
- Monthly lab measurements of the named pages on the agreed profile
- Your release notes or deployment dates, where you share them
- Your own real-visitor reports for the pages, where you can share them
When something happens
Scroll the table sideways to read it all.
| When | What we do |
|---|---|
| A named page's loading, layout stability or responsiveness measurement passes an agreed limit. | We trace the element or script behind the failing metric on a branch and open a pull request that fixes it, or tell you what you need to change. Priced as: Fix one page's Core Web Vital |
| A layout defect appears at a phone width on a named page. | We reproduce it at the agreed widths and open a pull request that fixes it, with before and after screenshots. Priced as: Fix a broken mobile layout |
| A release you have told us about goes out, within the four release checks a month. | We re-measure the named pages and tell you whether any limit was passed. Releases beyond the fourth in a month are measured at the next monthly measurement, or under a larger agreed scope. |
| A month ends. | We send a short written summary: figures for each page and metric, slips seen, pull requests opened and what is still open. |
We do on our own
- Measure the named pages and read your shared reports
- Reproduce and investigate slips on a branch
- Open pull requests that change the pages' styles, images, fonts or scripts you control
We ask you first
- Anything that changes hosting, content-network settings, tracking accounts or third-party scripts
- Merging, or any change to your production site
- Removing a feature or content to improve a number
We escalate to you when
- The cause is a third-party script or hosting setting outside your code
- A fix would change what the page does or shows, not only how fast it loads
- Slips pass the agreed monthly number
- Releases you tell us about pass four in a month
How you know it held. Each month you get the lab figures for every page and metric against its limit, the median of the five runs and all raw results, so you can repeat any measurement.
How we keep it true
This service is never finished. Each month's summary shows whether the named pages stayed inside their limits, and it continues until you end it.
Bring one Core Web Vitals metric on one slow page into the good range Job Each time it fires
One named metric on one named page passes its published good threshold (loading, layout shift) or a stated lab proxy (responsiveness) in agreed lab tests, with the cause written down.
Up to two a month, as agreed
Each slip we fix is the same job you can buy on its own.
Fix layout that breaks on phones or tablets for one page Job Each time it fires
Up to five named layout defects on one page are gone at four agreed screen widths, with before and after screenshots and an automated screenshot check you can keep.
Counted within the same monthly number
A layout defect found on a named page is fixed the same way as the one-off job.
What is included, and what is not
- A monthly results table for each named page and metric against its limit
- A fix pull request with before and after figures for each slip we can fix within the agreed number
- An explanation of what you need to change, when the cause is not in your code
- A written monthly summary
Included
- Monthly lab measurement of up to five named pages on one fixed profile, five runs each, with the median reported
- A release check on the named pages after a release you tell us about, up to four release checks a month (one release check is one re-measure of every named page on the fixed profile, five runs each)
- Investigation and a fix pull request for each page that passes an agreed limit, up to the agreed number a month
- A plain explanation, with evidence, when the cause is outside your code, such as a third-party script or hosting
- Your own real-visitor reports read alongside, where you can share them, with a note of what they can and cannot show
- A written monthly summary
Not included
- Merging, deploying or changing your hosting, content network or tracking accounts, which stay with your team
- A guaranteed ranking, traffic or conversion outcome
- Round-the-clock monitoring, alerts out of working hours or any guaranteed response time
- Fixing or removing third-party scripts you will not change
- New features, redesigns or pages beyond the five named
- Real-visitor figures by a fixed date: they update over 28 days
How we know it’s done
Agreed with you before work starts. Each check produces evidence you keep.
Each month's summary lists the median of five runs on the agreed profile for every named page and metric, with its limit and the status against it.
Evidence: The monthly results table with raw runs, which you can repeat with the same profile.
For each fix, the named metric on the named page is back inside its limit on the agreed profile, and no agreed element was removed.
Evidence: The before and after runs and screenshots in the pull request.
No file outside the pages named in each pull request is changed.
Evidence: The pull request diff, limited to the files named in its description.
Sign-off. You review and merge each pull request, and you read each monthly summary. A fix counts as delivered when you accept it.
If it fails. If we cannot fix a slip, we say so, explain what we found and what it would take, and it does not count against the monthly number. If the service is not working for you, you can end it at the end of any month.
When it fits, and when we stop
It fits when
- The named pages are public, or reachable at a staging address with the same scripts
- The pages' source can be changed through an agreed route, with pull requests that a person on your side reviews
- You agree the limits and the test profile in writing before the service starts
- You tell us about releases, or we compare each month's result with the last
We stop and tell you if
- Most slips are caused by third-party scripts or hosting that you cannot or will not change
- Slips regularly exceed the agreed number of fixes, so a different scope is agreed
- The pages cannot be tested reliably, for example because they depend on logged-in data we cannot simulate safely
- Releases regularly pass four a month, so a different scope is agreed
What could go wrong
Every fix is a pull request that your team merges, so you can revert it as you would any other change. Ending the service leaves your pages as they are, with our open pull requests finished or handed back.
Scroll the table sideways to read it all.
| Risk | How we handle it |
|---|---|
| A figure is improved by hiding or removing content. | Pull requests show before and after screenshots, and we do not remove content or features without your approval. |
| Lab figures drift from what real visitors experience. | We say so in each summary, read your real-visitor reports where you share them and keep lab results as the agreed measure. |
| Measurements vary and cause false alarms. | Each page is measured five times and the median is used, with all runs shown. |
Each pull request is checked by a reviewer separate from the work that produced it before it is opened, including a check that no content or feature was removed to improve a figure. No human supervisor is included unless your agreement names one. At launch the work is largely automated, and we say so.
Stays with a person
- You review and merge every pull request
- You approve any change to hosting, content-network settings or third-party scripts
Access we would need
- Public access to the named pages, or a staging address
- Access to a fork or branch for pull requests
Questions
How is this different from buying one fix?
A one-off fix repairs one metric on one page once. This is a standing responsibility: we measure the pages you name every month and take each slip through to a pull request or an explanation.
Do you monitor in real time?
No. Measurement is monthly and after up to four releases a month that you tell us about. There is no round-the-clock cover or response-time guarantee.
Will this improve my rankings?
We make no promise about ranking, traffic or sales. The service keeps measured figures inside limits you agree.
Send an enquiry
Send us
- The five page addresses and the metric or report that matters most to you
- Roughly how often you release changes to those pages
- Who reviews and merges a fix pull request
Later, once you agree
- Source access to the pages through an agreed company-controlled route, with a branch or fork for pull requests
- A staging address, if testing on production is not appropriate
- The agreed limits, test profile and number of fixes a month, in writing
You own the site, hosting and measurement accounts. We read public pages and work on a branch or fork through a company-controlled identity, never a personal login. We change files only through pull requests your team reviews and merges.
Email fallback: open your mail app
If website submission is unavailable, review and send the fallback email yourself. An email fallback is not a website receipt. Or write to hello@syntheticindustry.ai with “perf-keep-core-web-vitals-in-check” as the subject.