At 10 to 99 people you are past the DIY stage and not yet at the enterprise stage. You have a real website, a marketing generalist or a small team, and a budget that is finite but not zero. The trap at your size is treating site speed as a one-time cleanup: you pay someone to fix it once, the numbers look great for a quarter, then a new tag, a redesigned landing page, or a bolted-on chat widget quietly drags them back down and nobody notices until rankings slip. The fix is not a bigger one-time push. It is a small, repeatable process you own internally, run on a schedule, and can defend to an owner or finance lead with a number. This is that process, retold from the Core Web Vitals guide for the company that has to make it stick.
The three metrics, in one paragraph
Core Web Vitals are three measurements of how a page feels to a real visitor: how fast the main content shows up, how quickly the page responds when someone taps or clicks, and whether things jump around while it loads. Google buckets every measurement into good, needs improvement, or poor, and it ranks on the real experience of your actual visitors, not on a lab score. Your generalist does not need to become a performance engineer to run this. They need to know the three numbers, know the pass line for each, and know the loop that keeps them green.
- Largest Contentful Paint (LCP): how long until the biggest thing on screen, usually the hero image or headline, finishes loading. Good is under 2.5 seconds. Usually fixed by right-sized images and a fast platform.
- Interaction to Next Paint (INP): how fast the page reacts when a visitor taps the menu, opens an FAQ, or starts a form. Good is under 200 milliseconds. Almost always about trimming heavy JavaScript, which at your size means the third-party scripts different departments keep adding. INP replaced First Input Delay in 2024 and is stricter, so pages that used to pass can quietly fail it now.
- Cumulative Layout Shift (CLS): how much the page jumps around as it loads. Good is under 0.1. Fixed by reserving space for every image, ad, and embed so nothing shoves the content down when it arrives late.
Why a process beats a project at your size
A micro business can get away with fixing speed once, because their site barely changes. A large enterprise needs continuous monitoring across thousands of pages. You are in between, and the in-between failure mode is specific: you fix it once, then your own growth breaks it. Between now and next year your team will launch campaigns, add a scheduling embed, swap the analytics tag, redesign the pricing page, and turn on a chat widget. Every one of those is a chance to regress a vital, and because no single person owns the total, the regression lands invisibly. The company that stays fast is not the one that hired the best one-time fix. It is the one that made speed a checkpoint in how it already works.
The good news is that the process is cheap relative to the payoff. Speed is lead math: the longer a page takes to become usable, the more visitors leave before they read your pitch, and the ones who leave are disproportionately the expensive ones you paid to send there. For a company where a signed customer is worth real money, a homepage that loads a second and a half slower is qualified demand walking back out the door. A checkpoint that costs your generalist an hour a week protects a revenue line worth far more than the hour.
The score that ranks is not the one in your test tab
This is the trap that catches most teams at your size, because your generalist runs one test, sees a 90-something score, and reports the site is fast. That score is a lab result: one simulated device, one moment, your fast office connection. Google ranks on field data instead, the real Core Web Vitals of your actual visitors over the trailing 28 days. A great lab score and a failing field score sit side by side all the time, and only the field score touches your rankings. Build your process around the field number, not the lab number, or you will report green while quietly bleeding rank.
The repeatable process, in five steps
This is the loop your generalist runs. It is deliberately small so it survives busy quarters. Run the full loop monthly and a fast spot-check whenever anyone ships a change to the site.
- Measure the field data. Open the Core Web Vitals report in Google Search Console. It groups every URL into good, needs improvement, and poor, split by mobile and desktop, so you see which page templates fail rather than spot-checking one URL at a time. Record the counts. This is your baseline and your monthly comparison.
- Confirm on the worst offenders. Run the two or three failing templates through PageSpeed Insights to see which of the three metrics is red and why. If the real-user panel shows at the top, that is the field data that counts.
- Fix the top cause, not everything. Ship the single change that moves the most visitors from poor to good, usually an oversized image or an eager script. Resist the urge to rewrite the site.
- Guard the change. Add whatever you fixed to a short pre-launch checklist so the next campaign or redesign does not reintroduce it.
- Report the trend, not the day. A month after the fix, compare the Search Console counts. Report the shift in the field bands, tied back to conversion, to whoever funds the marketing budget.
Notice what this loop does not include: buying a real-user-monitoring platform, standing up a synthetic-testing rig, or hiring a performance specialist. Those are enterprise moves. At your size Search Console plus PageSpeed Insights is the whole toolchain, and both are free. Over-buying monitoring before you have a working loop just adds a tool nobody checks. The discipline is worth more than the dashboard. This is the same repeatable-process posture we bring to every engagement, laid out across our solutions.
Where the seconds go: the usual suspects at your size
Almost every Core Web Vitals failure traces back to a short, familiar list. At 10 to 99 people, the middle of this list is where you live, because your growth is exactly what adds the weight. In rough order of how often we find them:
- Oversized hero images and unoptimized photography. A four-megabyte banner is the single most common LCP killer, and it is the easiest to fix.
- Third-party scripts loaded eagerly: chat widgets, scheduling embeds, review carousels, tag managers, and analytics. Each one is someone else's JavaScript on your critical path, and INP is where it shows up. At your size these accumulate because different people add them and nobody owns the total.
- Page-builder and theme bloat. Drag-and-drop templates ship code for dozens of features you never use, and the browser downloads all of it anyway.
- Web fonts that block text from appearing until they finish downloading, so the page looks empty longer than it needs to.
- Images, ads, and embeds with no reserved space, which is exactly what drives layout shift as they pop in late.
- No caching or content delivery network, so every visitor waits on your origin server wherever it sits, instead of a copy served from nearby.
In-house versus outsource: where to draw the line
You do not have to choose all-in-house or all-outsource. Split it by what recurs. The measuring, reporting, and governance are recurring and cheap, so they belong in-house with your generalist. They are also the part that must not lapse, and an external vendor billed by the hour will not run your monthly loop for free. The deep fixes, a platform migration, a rebuild off a bloated page builder, a font and image-pipeline overhaul, are occasional and technical, and those are worth outsourcing to someone who does them all day.
- Keep in-house: the monthly Search Console read, the pre-launch checklist, the load-nothing-without-sign-off rule, and the ROI report to finance. This is the process, and the process is the point.
- Outsource the one-time depth: image and font pipelines, a move to a fast static-first platform, or untangling a page-builder theme. Buy the fix once, then run the loop yourself to keep it.
- Do not buy, yet: enterprise real-user monitoring, synthetic test networks, or a dedicated performance hire. Those earn their cost at hundreds of pages and continuous change, not at your size. Revisit them only when the free loop genuinely cannot keep up.
The two versions of this on either side of you make the line clearer. A micro business does the whole thing by hand in an afternoon and rarely revisits it, because their site barely moves. A mid-market team needs real governance and monitoring across many properties, with clear ownership and stakeholders. You are building the process that grows into theirs without paying for it before you need it. If you deliver this for other companies rather than run it internally, the agency version covers packaging it across a book of clients.
Measuring the ROI so the spend is defensible
The reason speed work stalls at your size is that it competes for budget against things with obvious numbers, like ad spend and a new hire. Fix that by giving speed its own number. You do not need a fancy attribution model. You need to connect the field-data trend to a business outcome your owner already cares about, and report both in the same view.
- Field-band movement. How many of your URLs moved from poor or needs-improvement into good this month? This is the headline, straight from Search Console, and it is the leading indicator for rankings.
- Conversion on the pages you fixed. Watch the conversion rate on a template before and after a speed fix. Faster pages keep more of the visitors who were about to bounce, and that shows up as more form fills on the same traffic.
- Cost of the inaction. Estimate the paid traffic landing on your slowest template and the share leaking to slowness. That leak is the budget the process protects, and it is the line finance understands fastest.
- Rankings on the fixed templates, one to two months later. Because of the 28-day field window, this lags. Report it as confirmation, not as the promise, so nobody judges the work by week two.
Where SMEs get this wrong
- Treating it as a one-time project. The fix that is not guarded gets undone by your own next launch. Build the checkpoint, not just the cleanup.
- Reporting the lab score. A green PageSpeed run on office wifi tells you nothing about what Google ranks. Report the field data or you are reporting a number that does not move rankings.
- Over-buying tooling. A real-user-monitoring subscription before you have a working monthly loop is a cost with no owner. Get the free loop running first.
- Letting every team add scripts freely. The slow site nobody meant to build is assembled one well-intentioned widget at a time. Govern what loads.
- Judging a fix by the same-week test. The field window is 28 days. Ship, wait, then read the trend, and set that expectation with finance up front.
Speed at your size is not a heroic one-time fix, it is a small process that survives your own growth. Run the loop monthly, govern what loads, keep the measuring in-house and outsource the depth, and give the whole thing a number your owner can defend. The full mechanics behind the three metrics live in the Core Web Vitals guide, and if your work is with professional services buyers the sector view is on who we serve. Google's own definitions are at web.dev, and you can test any URL on real field data at PageSpeed Insights.
Want to know your company's current field vitals and the two or three fixes that move them most? Run the estimator and we will measure it on real field data, or talk to us about standing up the repeatable process so it holds as you grow.
