A fast website sends little, sends it early, and does not move things around after they appear. Google measures this with three Core Web Vitals: LCP, how soon the main content shows; INP, how quickly the page reacts to a tap; and CLS, how much the layout shifts. Images, third party scripts, and fonts cause most slowness.
We work on two very different kinds of site. One kind is static: plain files with nothing running on the server. The other is WordPress, with a theme, plugins, and scripts from outside companies. Both can be fast. One of them is fast by default and the other has to be made fast.
This site is built without a framework, so there is no framework code for your browser to download before it can show you a page. That was a choice about speed. Here is what the measurements mean and what actually moves them.
What are Core Web Vitals?
Core Web Vitals are three measurements Google uses to describe how a page feels to a real visitor: how quickly the main content appears, how quickly the page responds to input, and how stable the layout is while it loads. They are collected from real browsers, not from a lab.
The names are abbreviations, and the ideas behind them are simple:
- LCP, Largest Contentful Paint. The moment the biggest thing on screen, usually a headline or a hero image, finishes drawing. It answers "can I see the page yet".
- INP, Interaction to Next Paint. The delay between a tap or click and the screen visibly reacting. It answers "does this page respond when I touch it".
- CLS, Cumulative Layout Shift. How much content jumps around as late items load. It answers "did the button move just as I went to press it".
Google documents all three at web.dev.
What is a good LCP, INP, and CLS score?
A good LCP is 2.5 seconds or less, a good INP is 200 milliseconds or less, and a good CLS is 0.1 or less. These are the thresholds Google publishes. A page passes when most real visits, not only the best ones, fall inside all three.
| Metric | What it measures | Good | Usual cause of a poor score |
|---|---|---|---|
| LCP | Time until the main content is visible | 2.5 s or less | Large images, slow server, render-blocking scripts and fonts |
| INP | Delay between input and visible response | 200 ms or less | Too much JavaScript running on the main thread |
| CLS | How much the layout moves while loading | 0.1 or less | Images without dimensions, late banners, font swaps |
What slows a website down the most?
Third party scripts, oversized images, and web fonts slow a website down the most. Each one adds downloads the visitor did not ask for, and scripts also keep the phone's processor busy. On many slow sites, the page's own content is a small share of what gets loaded.
In the order we check them:
- Third party scripts. Chat widgets, analytics, ad pixels, form protection, embedded maps, and video players. Each is code from another company running on your page. They are the first place to look because removing or delaying one costs nothing to try.
- Images. A photo straight from a phone camera is many times larger than a screen needs. Resize it, use a modern format, and give every image a width and height so the layout does not shift.
- Fonts. Every font file blocks or reshuffles text. Use few of them, host them yourself, and preload the one the headline uses.
- JavaScript you wrote or installed. Sliders, animation libraries, and page builder output all compete for the same processor.
- The server. A page assembled from a database on every visit starts later than a file that already exists.
We did a mobile performance pass on the Tamou Law Group site as part of a larger rebuild. That site runs WordPress with a caching plugin and a CDN in front of it. The lesson we took from that work applies to any site with a history: test on a phone first, and expect the gains to come from removing and delaying things, not from adding another optimizer. Our WordPress speed optimization checklist goes through that work in priority order.
Why are static sites usually faster?
Static sites are usually faster because the pages are built once, ahead of time, and served as finished files. There is no database query and no code running on the server per visit, so the first byte arrives sooner and there is less that can be slow.
The Gayer Law site is 305 static pages. A site of that size is as quick as a five page one, because serving page 305 is the same job as serving page one: send a file. There is also nothing on the server to patch.
That does not make WordPress the wrong choice. If several people need to edit content daily, an editor matters more than a few tenths of a second. We weigh the two in WordPress or a static site.
How do you test your website speed?
Test your website speed with Google's PageSpeed Insights, which shows two things: field data from real visitors over recent weeks, and a lab test run on a simulated phone. Trust the field data when it exists. Use the lab test to find what to fix.
A few habits make the results more useful:
- Test the pages people land on, not only the home page.
- Read the mobile result first. Phones are slower than your office computer and are what many local customers use.
- Run the test more than once. Lab scores vary between runs.
- Change one thing, then test again, so you know what helped.
Once a site is fast, the harder job is keeping it that way as new scripts get added. That is what a performance budget is for.
Frequently asked questions
Does website speed affect Google rankings?
Google has said that Core Web Vitals are among the signals its ranking systems use, and also that relevance comes first. A fast page with the wrong answer will not outrank a slower page with the right one. Speed is worth fixing mainly because slow pages lose visitors.
Do I need a perfect score of 100?
No. The score is a lab estimate, and the last few points often cost more effort than they return. Passing all three Core Web Vitals in field data is the practical goal. After that, attention is better spent on content.
Why is my site fast on my computer but slow on a phone?
Your computer has a faster processor, a faster connection, and a saved copy of the site's files from earlier visits. A first-time visitor on a mid-range phone has none of those. Test in a private window with the mobile setting to see what they see.
Will a caching plugin fix a slow website?
It fixes one cause: a slow server response. It does nothing about heavy images or third party scripts, which load in the visitor's browser after the cached page arrives. Caching is worth having, but it is not the whole job.
Does better hosting make a website faster?
It can shorten the server's response time, which helps LCP. It cannot shrink images or remove scripts, so a heavy page on expensive hosting is still heavy.
If your site is slow and you want to know why, send us the address. We will tell you what is weighing it down.