How to keep a small website fast: a practical guide

Why speed matters

A slow site loses visitors before they have even seen what you offer. People open websites on their phones, often on a patchy mobile connection, and they do not wait long. Speed is also part of how Google assesses pages: it is not the most important factor in search, but other things being equal, a faster and more usable page is in a better position.

There is a simpler reason too: a fast site looks maintained and reliable. A slow one gives the impression that nobody is looking after it.

Core Web Vitals in plain words

Google measures page experience with three main metrics called Core Web Vitals. The thresholds for “good” are:

• LCP (Largest Contentful Paint) ≤ 2.5 seconds — how quickly the largest element on the first screen appears, usually the big image or the heading.
• INP (Interaction to Next Paint) ≤ 200 milliseconds — how quickly the page responds when you tap a button or open a menu. INP replaced the older FID metric in March 2024.
• CLS (Cumulative Layout Shift) ≤ 0.1 — how much the content “jumps” while loading. The classic example: you are about to tap a link, a banner loads above it at the last moment and you tap something else.

Importantly, Google looks at data from real visitors, not just a lab test. So the site has to be fast on your customers’ average phone, not only on your office computer.

Images — the most common culprit

On most small sites, images make up most of the downloaded data. A photo uploaded straight from a phone or camera can be several megabytes and yet be displayed in a box 400 pixels wide.

• Resize images to the size at which they are actually displayed (with some headroom for high-density screens).
• Use WebP or AVIF — they usually give much smaller files than JPEG at similar quality.
• Add loading="lazy" to images below the first screen, but not to the main image at the top — that one needs to start loading immediately.
• Set width and height on every image so the browser reserves space and the content does not jump (this improves CLS).
• Don’t put a slider with ten huge photos at the top. One well-chosen image works better.

Fonts

A beautiful typeface can cost a second of loading time if it is set up carelessly. Every style — regular, bold, italic — is a separate file.

• Use two typefaces at most, and only the styles you actually use.
• Load only the scripts you need (subsetting) — for example Latin and Cyrillic, without Greek and Vietnamese.
• Set font-display: swap so the text shows immediately in a system font and the chosen one appears once it has loaded.
• If possible, host the fonts on your own site rather than an external server — that saves an extra connection.

Third-party scripts: the quiet speed thieves

A chat widget, an embedded map, a YouTube video, share buttons, several analytics tools, an ad pixel — each of these is code downloaded from someone else’s server and run on the visitor’s phone. Often it is these, not the site itself, that ruin INP.

• Make a list of all external scripts and ask about each one: who looks at its data, and when did they last do so?
• Remove anything nobody uses. There is no need for three analytics tools.
• Maps and videos can be replaced with an image that loads the real content only when clicked.
• The chat can load after a few seconds or on the visitor’s first interaction, rather than immediately.

Some of these services also set cookies that require consent — more on that in the practical GDPR and cookies checklist.

Caching, CDNs and hosting

Caching means that the browser or the server keeps a ready copy and does not rebuild it on every visit. Static files — images, styles, scripts — should have a long cache lifetime. A CDN (a network of servers around the world) delivers files from a point close to the visitor.

With WordPress and similar systems, the page is often assembled from the database every time it is opened. A good caching plugin, or hosting that provides caching, makes a big difference. Cheap shared hosting is perfectly adequate for a small site, but if the server is slow to respond before it has sent anything at all, no amount of image optimisation will help. More on choosing in the article on backups and hosting.

Plugins

Every plugin adds code, and often its own styles and scripts on every page — even pages where it is not used. A site with several dozen plugins is almost always slower and harder to update.

• Delete (not just deactivate) plugins you don’t use.
• Avoid two plugins that do the same thing.
• Before adding a new plugin, check whether your theme or system already does the same.
• Update regularly — besides security, new versions are sometimes faster too.

How to measure, and a monthly checklist

Free tools are enough. PageSpeed Insights shows both a lab test and data from real visitors (if the site has enough traffic). Lighthouse is built into Chrome and gives detailed recommendations. Don’t chase a score of 100 — the goal is green Core Web Vitals and a site that feels fast. And always open the site on an ordinary phone, on mobile data.

Set aside 20–30 minutes once a month:

1. Run PageSpeed Insights on the home page and on one or two of the most visited pages.
2. Check the new images uploaded during the month: size and format.
3. Review the list of external scripts — has anything new been added?
4. Update the system, theme and plugins (after you have a fresh backup).
5. Open the site on a phone using mobile data and complete the main action — a call, an enquiry, a booking.
6. Write down the results so you can see when something gets worse.

For the basics of usability on phones, see also mobile-first design. If you would rather have someone else look after speed, the TemidaSoft team builds and maintains websites for small businesses.