A small site is fast and accessible with the same handful of checks

A photograph straight off a phone camera is often 4000 pixels wide and several megabytes in size. Shown on a page at 800 pixels across, the browser still downloads the whole file and shrinks it in the browser, so the visitor pays in loading time for detail nobody sees. Getting image size right is usually the single biggest speed gain available on a small site, because one oversized photograph can outweigh every other file on the page combined.

What size to export at

Export an image at the largest size it will actually be displayed. A full-width hero image rarely needs to be wider than about 1600 to 2000 pixels, because almost no screen shows it larger than that, and a thumbnail or logo needs only a few hundred pixels. Exporting a 4000-pixel photograph into a 300-pixel thumbnail slot wastes bandwidth on both ends: the file is large to send and the browser still has to resize it before it can be shown.

• Hero or banner images: around 1600 to 2000 pixels wide is usually enough.
• In-page photographs: match the width to the column they sit in, typically 600 to 1000 pixels.
• Logos and icons: export at the size shown, or at most double that for sharper screens.

WebP against JPEG and PNG

WebP is an image format that generally produces a smaller file than a JPEG or PNG of the same visible quality, sometimes by a large margin on photographs. Most current browsers display WebP without difficulty, but if a build tool or content system does not generate it automatically, a JPEG (for photographs) or PNG (for logos and images needing a transparent background) is a perfectly workable fallback. Which format is available to you often depends on how the site is built, covered in more detail in choosing how to build it; some builders convert images to WebP on upload without being asked, others do not.

The one oversized image that slows the whole page

On most small sites that load slowly, the cause is not a dozen small problems but one large photograph, usually the hero image at the top of the home page, exported at full camera resolution and dropped in without resizing. That single file often becomes the largest thing the page has to load, and because it usually sits at the top of the page, it is also the element a browser judges the page's loading speed by. Checking that one image, its dimensions and its file size, is worth doing before looking at anything else on the page.

A system font is one already installed on the visitor's phone or computer, such as San Francisco on an iPhone or Segoe UI on a Windows laptop. The browser can draw it straight away because there is nothing to download, and for a small site that speed advantage is usually worth more than the extra polish a custom typeface brings.

What a web font brings, and what it costs

A web font is a typeface file the browser has to fetch before it can show your text in that style, usually in the WOFF2 format. Each weight, regular, bold, italic, is a separate file, so a page using four weights of the same family is downloading four files before the words on it look right. On fast broadband that delay is barely noticeable. On a mobile connection with a weak signal it can be the difference between text appearing straight away and a blank space for a second or two.

If a custom font matters for a logo or a strapline, one weight is usually enough. Two at most for a small site: one for body text, and a second for headings if they need to look distinct from the rest of the page.

Font-display: swap, and why it is normally the right setting

The font-display property tells the browser what to do while a web font is still loading. Set to swap, it shows the text right away in a system font and switches to the custom one once it arrives, so the visitor reads the content. Left unset, some browsers hide the text entirely until the font is ready, which is the more common cause of a page that looks blank for a moment on a slow connection. There is little reason on a small site not to set it to swap.

Three measurements decide whether a page feels quick or feels stuck, and Google uses all three as it decides how to rank a page. They are collectively called Core Web Vitals, and each one tracks a different kind of delay: how long the main content takes to appear, how much the page shifts around while it loads, and how quickly it responds once someone actually touches it.

How long the biggest thing takes to show up

The first measure tracks how long the largest visible element on the page, usually a hero image or a main heading, takes to render. This is called Largest Contentful Paint (LCP). A score of 2.5 seconds or under counts as good; anything past 4 seconds counts as poor, with the range between the two flagged as needing work. On a small site this number is almost always about image weight: a hero photograph exported at full camera resolution and left unresized is the single most common cause of a slow LCP score.

How much the page jumps around while it loads

The second measure tracks how much visible content moves after it has already appeared, which is the jolt a reader feels when text they were about to read slides down because an image has just popped in above it. This is called Cumulative Layout Shift (CLS), and a score of 0.1 or under is good. The fix is usually simple: give every image a fixed width and height in the page code before it loads, so the browser reserves the right amount of space and nothing has to shuffle once the file arrives.

How quickly the page responds to a tap

The third measure tracks the gap between someone tapping a button or a link and something visibly happening on screen. This is called Interaction to Next Paint (INP), and a score of 200 milliseconds or under is good, with anything over 500 milliseconds counted as poor. On a small site this delay usually comes from heavy third-party scripts, such as chat widgets or tracking code, competing for the browser's attention at the exact moment someone tries to click something.

Why small sites usually clear these numbers without much effort

A static site, meaning one built from plain HTML pages, has a natural advantage here: there is less code running, so there is less to slow it down or shift about. Where these scores are still poor, the cause is nearly always an oversized image or a script that did not need to be there, both of which are worth checking before assuming the platform itself is at fault. If you are still deciding how to build the site in the first place, Choosing How to Build It: Criteria, Not Brands sets out how that choice affects speed later on.

Free browser developer tools and page-speed checkers will report all three scores for any live page, though like any automated check they can flag a false problem or miss a real one, so treat the numbers as a starting point for investigation.