--- title: "Core Web Vitals: What a Small-Business Owner Should Check Before June 2021" description: "Google just confirmed that its Page Experience update, which folds Core Web Vitals into mobile search ranking as a signal, will start rolling out in mid-June instead of May as originally planned. That buys a few extra weeks, not a reason to wait. The best way to know where you stand is to check now, ... Read more" canonical: "https://socialinfluencebuilder.com/en/blog/core-web-vitals-check-small-business/" lastmod: "2021-04-21T16:48:00+00:00" lang: "en-CA" format: "markdown" --- HTML version: # Core Web Vitals: What a Small-Business Owner Should Check Before June 2021 Google just confirmed that its Page Experience update, which folds [Core Web Vitals](/en/glossary/#core-web-vitals) into mobile search ranking as a signal, will start rolling out in mid-June instead of May as originally planned. That buys a few extra weeks, not a reason to wait. The best way to know where you stand is to check now, before the rollout starts, rather than find out once it is already underway. Here is what I look at first when a small-business owner asks where their site sits, and the fixes I prioritize on WordPress. ## What are Core Web Vitals, exactly? Core Web Vitals are three measurements Google uses to judge how a real visitor experiences a page: loading speed, responsiveness to clicks, and visual stability while the page loads. Each one has a specific threshold. - **LCP (Largest Contentful Paint)** measures how long the biggest visible element on the page (usually a header image or headline) takes to render. Google's target is 2.5 seconds or less. - **FID (First Input Delay)** measures the gap between the moment a visitor clicks or taps something and the moment the browser actually responds to that click. Google's target is 100 milliseconds or less. - **CLS (Cumulative Layout Shift)** measures how much the page's elements jump around while it loads, for example when a button shifts position right before you click it because an image above it just finished loading. Google's target is a score of 0.1 or less. All three are measured separately for mobile and desktop, because the results are rarely identical on both. ## Will the Page Experience update actually change your rankings in June? Probably very little, and that is worth saying plainly before anyone panics over a score. Google has been explicit that content quality and relevance still outweigh page experience, and a page that answers a search better can still outrank a faster page that answers it worse. The new signal mostly acts as a tiebreaker between two pages that are otherwise close on content. The rollout itself is spread over several weeks starting mid-June, not switched on all at once, so nobody should expect a sudden traffic shift on day one. What I tell clients is that Core Web Vitals are worth fixing even if rankings did not move at all, because a faster, more stable site converts better. That is the real reason to deal with it. The ranking signal is a bonus on top. ## How do you check your own Core Web Vitals right now? Two free tools give you a first read. **PageSpeed Insights**, Google's free tool, analyzes one URL at a time and returns two kinds of data: field data, pulled from real Chrome visitors over the past 28 days if the site gets enough traffic to have any, and lab data, generated on the spot from a simulated test. Field data is what Google actually uses for ranking; lab data is mainly there to help diagnose why. **The Core Web Vitals report in Search Console** gives a site-wide picture instead of a single page. It groups your URLs by status (Poor, Needs Improvement, Good) separately for mobile and desktop, which helps show whether the problem affects the whole site or just one type of page, like product listings or blog posts. I always start with Search Console to see how big the problem is, then use PageSpeed Insights on the highest-traffic pages to pin down the exact cause. ## How do I walk a client through a PageSpeed Insights report in plain language? The first thing I do is ignore the big number at the top of the report, the score out of 100. That score blends several technical measurements into one figure that does not mean much to a small-business owner and can be misleading on its own, because a site can score poorly overall while still passing all three Core Web Vitals. I go straight to the three metrics and translate each one. For LCP, I look at whichever element Google flagged as the largest on the page, almost always a hero photo or main headline, and explain that it is specifically that image slowing everything down, not the site in general. For CLS, I scroll the page with the client while it loads and show them live the button or menu that jumps position, which makes the problem concrete instead of abstract. For FID, since that measurement comes from real visitors and does not show up in a simulated test, I explain instead what usually causes a delay, often an ad script or a chat widget that ties up the browser during load. The point of this step is not to turn the client into a performance expert. It is to show them that every number on the report maps to something real and fixable on their own site. ## Which WordPress fixes get priority? Across most small-business WordPress sites I have checked this year, the same causes keep showing up, and I fix them in this order. 1. **Uncompressed, oversized images.** This is the most common cause of a poor LCP. A 4,000-pixel-wide photo loaded into an 800-pixel space forces the browser to download a file far heavier than it needs. I compress and resize the image to the size it is actually displayed at before putting it back online. 2. **Hosting and caching.** Cheap shared hosting serving hundreds of sites off the same server often produces a slow initial response time, no matter how well the rest of the site is optimized. I add a caching plugin and, where the budget allows, recommend switching hosts. 3. **Scripts that block rendering.** Every chat widget, image carousel, and social media plugin adds a script the browser has to load before it can show the rest of the page. I remove or delay whatever is not essential to that first second of display. 4. **Images with no reserved dimensions.** This is the most common cause of a poor CLS: without width and height specified in the code, the browser does not know how much space to leave for an image before it finishes loading, so everything below it jumps around. Adding the missing dimensions usually fixes this almost instantly. Those four fixes cover most of what I see, and they rarely require rebuilding the whole site. ## What can wait until after June? Not everything needs to be perfect before the rollout. Once the four fixes above are in place, the rest (finer font-loading tweaks, lazy-loading images below the fold, a full hosting review) can happen gradually, since the rollout itself stretches over several weeks and relevant content still outweighs speed in ranking. What matters most before June is knowing where you stand and having fixed the heaviest causes, not chasing a perfect score. This is the check I run before starting any [website redesign](/en/conception-web/): measure the current Core Web Vitals, fix whatever is heaviest first, then rebuild on that foundation instead of stacking a new design on top of the same problems. *Drafted with AI assistance, checked and published by [Marven Salgado](/en/about/marven-salgado/).* ## Go further - **Service:** [Web design in Montreal built to convert visitors into customers](https://socialinfluencebuilder.com/en/conception-web/) - **Case study:** [Filet Gourmet](https://socialinfluencebuilder.com/en/filet-gourmet/) - **Glossary:** [Digital marketing glossary: Core Web Vitals](https://socialinfluencebuilder.com/en/glossary/#core-web-vitals)