Job perf-one-core-web-vital-one-page · revised 11 October 2026
Bring one Core Web Vitals metric on one slow page into the good range
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.
You might be seeing
- The main image or heading on the page appears several seconds after the page starts loading
- Content jumps around while the page loads, so people tap the wrong thing
- The page is slow to react when someone taps a button or opens a menu
No passwords, keys, card details or admin invites needed to start.
What usually happened
One page misses a published good threshold for one Core Web Vitals metric, but nobody has identified which part of the page causes it. Changing images, plugins or hosting without measuring first often spends money and moves nothing. The job measures one page on a fixed test profile, identifies the element and the delay behind the failing metric, and fixes that cause.
Who it’s for: A site or product owner whose important page (home, landing, product or sign-up) is flagged by a search or speed report as slow to load, jumpy or slow to respond, and who wants one page measured and fixed before spending on a wider rebuild.
Usually starts when: A report such as PageSpeed Insights or Search Console lists one page or page group as needing improvement for one metric, or a new design, image, script or embed made the page noticeably worse.
The result: On one named page, one named metric reaches its good threshold (for responsiveness, the lab proxy Total Blocking Time under 200 milliseconds) in the median of five lab runs on an agreed device and network profile, and a second profile does not get worse. You receive the before and after measurements, the identified cause and the change. Real-visitor results are reported separately once they have had time to update.
Check whether this job fits
Answer from the report you already have. These questions check whether one metric on one page is the right size of job; they need no access.
Checks you can run yourself
Run the page through a public speed report twice
Open a public speed report for the page address, choose the mobile setting and run it twice, a few minutes apart. Note which metric fails and what the report names as the element behind it.
Look for: Whether the result changes much between runs, which metric fails and whether the report names a single image, heading or script. Send the figures, not your login.
What you get
- A pull request with the change and a note explaining the cause
- Before and after lab results for both profiles, with the raw run results
- A list of anything found that we did not change, in order of likely value
- Reversal steps and any limits found
Included
- One page at one address, one metric chosen at the start from loading (Largest Contentful Paint), layout stability (Cumulative Layout Shift) or responsiveness (Interaction to Next Paint, using Total Blocking Time under 200 milliseconds as the lab stand-in)
- Measure the page five times on each of two agreed profiles, and keep the traces
- Identify the element or script behind the failing metric and the part of the delay it belongs to
- Fix that cause within your page templates, styles, images, fonts or scripts you control
- Re-measure on the same profiles and report the before and after figures
Not included
- Fixing every metric on every page, or a whole-site speed programme
- A guaranteed change to search ranking, traffic or sales
- Real-visitor (field) results by a fixed date: they are an average over 28 days and depend on your visitors
- Changing third-party scripts you do not control, other than loading them differently
- Hosting or content-network changes and server upgrades, which stay with your team
- Rebuilding the page design or moving it to another framework
How we know it’s done
Agreed with you before work starts. Each check produces evidence you keep.
On the first agreed profile, the median of five lab runs for the named metric on the named page is within its target: 2.5 seconds for Largest Contentful Paint or 0.1 for Cumulative Layout Shift (their published good thresholds), or, for responsiveness, a Total Blocking Time under 200 milliseconds, with a mobile profile agreed as the first profile when responsiveness is chosen. Total Blocking Time is a lab proxy for Interaction to Next Paint, not the same measure; Interaction to Next Paint itself is a real-visitor metric and is reported separately, not tested here.
Evidence: All five raw run results before and after, with the profile settings and dates.
On the second agreed profile the same metric is no worse than before, and none of the other two metrics worsens by more than the agreed tolerance.
Evidence: The same raw results for the second profile and for the other metrics.
The page at the agreed desktop and phone widths shows every agreed element and the agreed interactions still work.
Evidence: Before and after screenshots and a short checklist result for each agreed interaction.
The diff contains no secret and does not remove an agreed feature, and the existing page tests, or an agreed manual check, still pass.
Evidence: The changed-file list, a secret scan of the diff and the test results.
Sign-off. You or your authorised maintainer review the measurements and the page, sign off in writing and merge. Payment follows sign-off. Real-visitor figures are shared when they have had time to update and are not a condition of payment.
If it fails. If the agreed lab threshold is not met on the first profile, you do not pay for this fixed scope. If the cause is outside what we can change, such as a third-party script you will not alter, we explain what we found and stop. Wider work needs a new written agreement.
When it fits, and when we stop
It fits when
- One page is publicly reachable, or can be reached at an agreed staging address with the same content and scripts
- The page's source and build can be changed through an agreed route after scope is agreed
- The slow metric can be seen in a lab test, not only in rare field cases
- An authorised maintainer on your side reviews and merges the change
We stop and tell you if
- The cause is a third-party script or service you will not change or remove
- The metric is failing only for reasons outside the page, such as a slow origin server we cannot change
- The page is built by a closed tool whose output you cannot edit
- Fixing the metric would need a redesign of the page
What could go wrong
Before merge, closing the pull request leaves the page unchanged. After merge, your maintainer can revert the commit. Any image or font files we add are listed so they can be removed.
Scroll the table sideways to read it all.
| Risk | How we handle it |
|---|---|
| The metric improves in the lab but not for real visitors. | We say in advance that lab results are a controlled test, and report field data separately once it has updated. Acceptance is the agreed lab result. |
| The number is improved by hiding or delaying useful content. | The reviewer compares the page before and after at agreed widths and checks that every agreed element is still present and usable. |
| Results vary between runs and a lucky run is reported. | The result is the median of five runs on each profile, with all runs shown. |
An independent reviewer checks that the before and after runs used the same profiles, that the median figure is correctly taken, and that the change did not hide content or remove a feature to improve the number. Your maintainer reviews and merges.
What you can check
This is a new service. We have not delivered this job for a client yet.
Other ways to get this done
Questions
Will my search ranking improve?
We make no promise about ranking, traffic or sales. The job delivers a measured improvement on one page.
Why do you test in a lab if real visitors are what matter?
A lab test is repeatable, so a pass can be checked by you. Real-visitor data is an average over 28 days; we report it afterwards but it cannot be a payment condition.
What if three metrics fail?
Choose the one that matters most for this page. The other findings come back as an ordered list, and each further metric is its own job or part of a project.
Do you change my hosting?
No. Hosting and content-network settings stay with your team; we tell you if they are the cause.
Send an enquiry
Send us
- The page address and the metric you were told is failing, with the report it came from
- Which technology the page is built with, and whether you can change it yourself
- Which devices matter most to your visitors
- Do not send credentials, source code or customer data in the first enquiry
Later, once you agree
- The page source and build through an agreed company-controlled route, with a branch for the pull request
- A preview or staging address with the same content, if production cannot be used for testing
- Access to your existing reports for the page, with identifying details removed
- The name of the person who reviews and merges
You own the site, the hosting and any measurement accounts. We work on a branch or preview through a company-controlled identity, never a personal login. We test public pages or a staging copy and need no analytics login. Your team deploys.
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-one-core-web-vital-one-page” as the subject.