Website speed optimization makes your pages load, respond and stay steady quickly on real phones, measured by Google's Core Web Vitals: LCP, INP and CLS. We find what slows your site, replace heavy parts with lean, W3C-valid code, add security headers and track real-visitor data instead of chasing a one-time score.
Core Web Vitals in Plain English
Core Web Vitals are three measurements Google uses to describe how a page feels to the people using it. Each one answers a simple question a visitor would ask without knowing the jargon.
- Largest Contentful Paint (LCP): how long until the biggest image or block of text on the screen appears. In plain terms, "Has it loaded yet?"
- Interaction to Next Paint (INP): how quickly the page visibly responds after a tap, click or key press. "Did it notice I tapped that?"
- Cumulative Layout Shift (CLS): how much the content jumps around while the page loads. "Why did the button move just as I went to press it?"
The thresholds below come from web.dev's guides to Web Vitals (opens in a new tab) and how the thresholds were defined (opens in a new tab). Google recommends measuring them at the 75th percentile of page loads, separately for mobile and desktop, so the target has to hold for most of your visitors, not just the ones on fast connections.
| Metric | What it measures | Good | Needs improvement | Poor |
|---|---|---|---|---|
| LCP | Loading of the main content | 2.5 seconds or less | Over 2.5 and up to 4 seconds | Over 4 seconds |
| INP | Responsiveness to taps, clicks and typing | 200 milliseconds or less | Over 200 and up to 500 milliseconds | Over 500 milliseconds |
| CLS | Visual stability while loading | 0.1 or less | Over 0.1 and up to 0.25 | Over 0.25 |
INP is the newest of the three. It replaced First Input Delay as a Core Web Vital on March 12, 2024 (opens in a new tab). Where the old metric looked only at the delay before the first interaction, INP looks at how responsive the page is across the whole visit, which is why heavy scripts that run after the page appears now count against a site.
What Google Says About Speed and Rankings
Google's guide to understanding page experience in Google Search results (opens in a new tab) states that Core Web Vitals are used by its ranking systems. The same page is careful to add that good results in Search Console or third-party tools do not guarantee your pages will rank at the top, and that Google always seeks to show the most relevant content, even when the page experience is sub-par. The page experience questions Google lists go beyond speed, too: whether pages are served securely over HTTPS, whether they display well on mobile devices and whether they avoid intrusive interstitials.
So speed is one signal among many. It will not lift a page that fails to answer the search, and a slow page with the best answer can still rank. We never promise ranking gains from performance work. The stronger reason to care is the visitor: someone comparing two charter companies or two cafes on a phone has little patience for a page that stalls, jumps or ignores a tap.
Lab Data and Field Data: Reading PageSpeed Insights Correctly
PageSpeed Insights shows two kinds of results, and confusing them is the most common mistake we see. According to Google's About PageSpeed Insights (opens in a new tab) documentation, field data comes from the Chrome User Experience Report and reflects real visitors over the previous 28 days, while lab data comes from Lighthouse, which loads the page in a simulated environment on one device with fixed network settings. The two can disagree, and both are useful.
- Field data tells you what real visitors experienced. It is the closest thing to the truth, but low-traffic pages often have too little data to show.
- Lab data is repeatable and explains why a page is slow, pointing to the specific images, scripts and styles involved.
- Search Console's Core Web Vitals report groups your URLs by field data over time, which makes it the best place to confirm that a fix worked.
About a perfect score: Lighthouse treats a performance score of 90 to 100 as good, and we test every page we build before launch, aiming for green and often 100. But a lab score is a test on one simulated device. We judge success by field data from your real visitors, because that is what Google and your customers experience.
What Slows Down Small Business Websites
When we audit a slow coastal business site, the cause is rarely the hosting alone. It is usually a pile of reasonable-sounding additions that each cost a little, until together they cost a lot.
- Heavy themes and page builders: CSS and JavaScript for dozens of features loaded on every page, including features the site never uses.
- Sliders at the top of the page: several large images competing to be the main content, often loaded by a script, with layout shifts as each slide appears.
- Unoptimized images: phone photos uploaded at full resolution, old formats instead of WebP, and no width and height attributes, so the layout jumps as images arrive.
- Third-party scripts: chat widgets, review carousels, social feeds, tracking pixels and booking embeds, each adding requests and main-thread work that hurt INP.
- Render-blocking CSS and fonts: several stylesheets in the page head, fonts loaded from outside servers and font weights nobody uses.
- Maps and videos on every page view: full embedded players and maps loading for every visitor, whether or not anyone presses play.
- Overlapping plugins: two or three tools doing the same job, each loading its own files.
- No caching or compression: files sent uncompressed and downloaded again on every visit, on top of a slow server response.
How We Make Sites Fast
Measure first
We collect field data where it exists, run Lighthouse on mobile and desktop, and read the network waterfall to find the LCP element, the long tasks and the files blocking the first render.
Fix the images
WebP files, responsive sizes with srcset and sizes, explicit width and height to prevent layout shift, and lazy loading below the fold. Following web.dev's guide to optimizing Largest Contentful Paint (opens in a new tab), we never lazy-load the main hero image; we give it high fetch priority or preload it instead.
Host fonts ourselves
Self-hosted WOFF2 files, trimmed to the characters and weights the design uses, with the main font preloaded so text appears quickly.
Lean CSS and JavaScript
Hand-written, minified external files the browser can cache, plain JavaScript instead of large frameworks where it does the job, and scripts deferred so they never block the first paint.
Click-to-load facades
Maps, video players and chat widgets load a lightweight preview first and the real embed only when someone uses it, a technique described in Chrome's guide to lazy loading third-party resources with facades (opens in a new tab).
Caching and compression
Gzip or Brotli compression, long cache lifetimes for versioned files and sensible cache headers for pages, so returning visitors download almost nothing.
Re-test and set a budget
We re-run every test after changes and agree on a simple performance budget, so a new widget or tracking script gets weighed before it is added, not after the site slows down.
This page follows the same rules: one minified stylesheet, a self-hosted and preloaded font, no hero photo and no third-party scripts. The same habits carry through every custom website design and web development project we take on.
W3C Validation and Why Valid Code Matters
Before launch we check every page's HTML with the W3C Nu Html Checker (opens in a new tab) and its stylesheets with the W3C CSS Validation Service (opens in a new tab). Browsers are forgiving: they will guess what broken markup was meant to say. The trouble is that different browsers, and different assistive technologies, can guess differently.
- Predictable structure: screen readers depend on correct headings, lists, labels and buttons, which ties directly to our ADA website accessibility work.
- Fewer surprises: valid code is less likely to break after a browser update or on a device you did not test.
- Easier maintenance: clean, standard code is quicker and cheaper for any developer to change later.
To be candid, Google does not reward validation for its own sake. Its guide to generative AI features in Search (opens in a new tab) notes that perfectly semantic HTML is not required and that Google can understand the web even though most of it is not valid. We validate because it is good craftsmanship that prevents bugs and supports accessibility, not as a ranking trick.
HTTPS and Security Headers
HTTPS is the baseline: it encrypts the connection, and Google's page experience guidance asks whether your pages are served securely. Security headers go a step further. They are short instructions your server sends with each page, telling the browser to enforce protections it would not apply on its own. They cost almost nothing in speed and close common gaps.
| Header | What it does | How we typically set it |
|---|---|---|
| Strict-Transport-Security (HSTS) | Tells browsers to reach your domain over HTTPS only and to upgrade any future plain HTTP request automatically. | A long max-age, with includeSubDomains once every subdomain supports HTTPS. |
| Content-Security-Policy (CSP) | Restricts which scripts, styles, images and frames a page may load, which helps prevent cross-site scripting and data injection attacks. | Your own files by default, with each outside service listed on purpose. |
| X-Content-Type-Options | Stops browsers from guessing a file's type, blocking attacks that disguise one kind of file as another. | nosniff |
| Referrer-Policy | Controls how much of your page address is shared when a visitor follows a link to another site. | strict-origin-when-cross-origin, set explicitly. |
| Permissions-Policy | Allows or denies browser features such as the camera, microphone and location, including inside embedded frames. | Features the site does not use are switched off. |
The descriptions above follow MDN's documentation on Strict-Transport-Security (opens in a new tab) and Content Security Policy (opens in a new tab). A strict CSP is the hardest of the five to apply to a site full of plugins, because every widget needs its own exception. On a hand-coded site with no inline scripts it is straightforward, which is one more reason we build the way we do.
Monitoring After Launch
Speed is not a one-time project. Sites slow down gradually as photos, plugins and tracking codes are added. After launch we keep an eye on the signals that matter:
- Search Console's Core Web Vitals report for trends in real-visitor data.
- Lighthouse and PageSpeed Insights checks on your key page templates.
- A re-test after every new plugin, widget, embed or marketing script.
- Security header and certificate checks with our own website scanner.
- Uptime and certificate-expiry alerts, which we recommend for every business site.
Fast, valid, secure pages also make the rest of your marketing work better. They give our local SEO and answer engine optimization work a solid base to build on.
Frequently Asked Questions
Why does my site feel fast on my computer but score poorly in PageSpeed Insights?
Your computer probably has a fast connection, a strong processor and your site's files already cached. PageSpeed Insights runs Lighthouse in a simulated environment on a single device with fixed, slower network settings, much closer to a visitor opening your site for the first time on a phone at the beach. That is the experience we optimize for.
Will a faster website rank higher on Google?
It can help, but it is not a shortcut. Google says Core Web Vitals are used by its ranking systems, and also that good scores do not guarantee top rankings and that the most relevant content can still rank with a weaker page experience. Speed matters to the people visiting your site whether or not it moves your rankings.
What is a good PageSpeed Insights score?
Lighthouse treats a performance score of 90 to 100 as good, and we aim for green scores on mobile and desktop before launch. The field data in the same report matters more: Largest Contentful Paint of 2.5 seconds or less, Interaction to Next Paint of 200 milliseconds or less and Cumulative Layout Shift of 0.1 or less for most real visitors.
Can you speed up my existing website without rebuilding it?
Often, at least partly. Resizing and converting images, removing unused plugins and scripts, adding click-to-load facades for maps and videos and turning on caching and compression can make a real difference. When a heavy theme or page builder is the main problem, a rebuild may cost less than patching. We tell you which after an audit.
Do security headers slow a website down?
Not in any way a visitor would notice. They are a few short lines of text sent with each page, and the browser simply enforces them. A strict Content Security Policy can even encourage leaner pages, because every outside script has to be approved on purpose.
Does W3C validation matter if my site already looks fine?
Looking fine in one browser is not the same as working everywhere. Valid HTML and CSS give browsers and screen readers a predictable structure, which prevents layout bugs and accessibility problems that are hard to spot by eye. Google says it does not require perfectly valid HTML, so we validate for reliability, not as a ranking trick.
Sources and Further Reading
- web.dev, Web Vitals (opens in a new tab)
- web.dev, How the Core Web Vitals metrics thresholds were defined (opens in a new tab)
- Google Search Central, Understanding page experience in Google Search results (opens in a new tab)
- Google for Developers, About PageSpeed Insights (opens in a new tab)
- Chrome for Developers, Lazy load third-party resources with facades (opens in a new tab)
- W3C, Nu Html Checker (opens in a new tab)
- MDN Web Docs, Content Security Policy (CSP) (opens in a new tab)