The real test of a business website is a customer in a parking lot with one bar of signal, and passing it is mostly a matter of sending that phone less: smaller images, fewer scripts and a page that shows its most important content first.

Eight Nights · Part 7 of 8 · See the full series

Google reads the phone version first

Google says it uses “the mobile version of a site’s content,” crawled with its smartphone agent, for indexing and ranking. Its mobile-first guidance follows from that: the mobile site should carry the same content as the desktop site, the same structured data, equivalent page titles and descriptions, and the same robots tags. Google also says not to lazy-load primary content upon user interaction, such as a tap or click.

In practice, anything a mobile theme hides, such as hours tucked behind a menu that loads on tap or a services list dropped to save space, risks being missed. As far as search is concerned, the phone view is the site.

Three numbers that describe speed

Google’s Core Web Vitals turn “fast” into three measurements, and web.dev publishes the thresholds.

• Largest Contentful Paint (LCP) measures how long the main image or block of text takes to appear. Good is 2.5 seconds or less; poor is more than 4 seconds.
• Interaction to Next Paint (INP) measures how quickly the page responds to taps and clicks. Good is 200 milliseconds or less; poor is more than 500.
• Cumulative Layout Shift (CLS) measures how much the page jumps around while loading. Good is 0.1 or less; poor is above 0.25.

The scores are judged at the 75th percentile of page views, meaning a page rates good only if at least three out of four visits meet the target. The same thresholds apply on phones and desktops. Google Search Central says it highly recommends good Core Web Vitals and that they align with what its core ranking systems reward. It is equally clear about the limit: Google says Search “always seeks to show the most relevant content, even if the page experience is sub-par.” Speed helps most when several useful pages compete for the same search.

Test like a customer, not like the office

An office laptop on a fast connection is a poor place to judge a website. Three free tools give a truer picture.

• PageSpeed Insights shows two kinds of results. Field data comes from the Chrome User Experience Report, built from real Chrome visits, and reflects what customers actually experience. Lab data comes from Lighthouse, which loads the page on a simulated mid-range phone over a throttled mobile connection and is best for finding what to fix. Pages with too little traffic fall back to data for the whole site.
• Search Console’s Core Web Vitals report groups similar pages, splits results by mobile and desktop, and labels each group good, needs improvement or poor. A group takes the status of its worst metric.
• Chrome DevTools device mode includes “Mid-tier mobile” and “Low-end mobile” presets that slow both the network and the processor. Google’s documentation calls device mode a first-order approximation and recommends a real device for accurate results.

The most honest test is still the cheapest: an ordinary phone, Wi-Fi off, standing at the far end of the building.

Start with the images

Chrome’s Lighthouse documentation says large downloads are highly correlated with long load times and can cost visitors money on cellular data plans. Images are the easiest place for most owners to start cutting that weight, with three fixes.

Pick the right format. web.dev recommends JPEG, lossy WebP or AVIF for photos, and says WebP and AVIF generally compress better than older formats and should be used where possible; both work in all modern browsers. PNG preserves fine detail at the cost of much larger files, and vector graphics suit logos and icons.

Send the right size. A photo sized for a wide desktop monitor is wasted on a phone. The srcset and sizes attributes let the browser choose a smaller file for a smaller screen, and Lighthouse flags images that are larger than the space they fill. For WordPress, Chrome’s documentation advises uploading through the media library so the smaller sizes are generated, and avoiding “Full Size” images unless the dimensions are actually needed.

Reserve the space. web.dev recommends width and height attributes on every image so the layout does not jump as pictures arrive, which protects the CLS score.

Lazy-loading, done carefully

Adding loading="lazy" to an image tells the browser to wait until the visitor scrolls near it. web.dev advises using it only for images outside the first screen. The large photo at the top of a page can be the element that sets LCP, and lazy-loading it delays exactly the moment being measured. Browsers that do not support the attribute simply ignore it.

WordPress core adds loading="lazy" automatically to images that carry width and height attributes, including those in post content and excerpts. That default is helpful further down a page, but it is worth checking that a theme or plugin has not applied lazy-loading to the hero image as well.

Fewer third-party scripts

Third-party scripts are code loaded from someone else’s server: social sharing buttons, video embeds, advertising frames, analytics and testing tools. web.dev notes they can add requests to several outside servers and keep the phone’s processor busy, delaying both the first view and the response to taps. Its advice is direct: if a script does not add clear value, remove it. For the rest, load scripts with async or defer unless they are essential to the first render, and delay embeds such as videos until the visitor scrolls near them.

A useful exercise is a one-page script inventory: every tracking pixel, chat bubble, pop-up and widget on the site, who asked for it and when anyone last looked at its results. Scripts with no owner are candidates for removal.

The Fenway Web Take

Speed is usually filed under marketing, but it behaves like continuity. A page that loads on office Wi-Fi and stalls on one bar of signal is effectively down for the customer who is trying to find the address, call or pay. Fenway Web’s recommended order of work is simple: measure the mobile scores first, fix images, cut scripts, confirm the top image is not lazy-loaded, then measure again so the change is visible. Most of that work removes things rather than adds them. Fenway Web offers clients a free continuity review.

Tonight’s checklist

• Run the home page and the busiest landing page through PageSpeed Insights on the mobile tab.
• Write down LCP, INP and CLS, and whether each is rated good.
• Load the site on a phone with Wi-Fi off, away from the router.
• Replace oversized photos with properly sized WebP or AVIF versions.
• Confirm the main image at the top of each key page is not lazy-loaded.
• List every third-party script and remove those nobody can justify.
• Compare the mobile and desktop pages to make sure no important content is missing on the phone.

What it means for you

• Google ranks the mobile version of the site, so that is the version to perfect.
• Aim for LCP of 2.5 seconds or less, INP of 200 milliseconds or less and CLS of 0.1 or less.
• Smaller, modern-format images are one of the simplest improvements to make.
• Every widget and tracking script has a speed cost and should earn its place.

The post Work on a Weak Signal: Making a Small Business Site Fast on Any Phone appeared first on Boston Made, Inc. | Boston, Massachusetts, USA.