How to build a fast website with AI (and what actually slows sites down)

"Which is the fastest CMS?" is the question most people start with. It's the wrong first question. A content management system decides how pages are stored and served, but the things that made the sites in our data slow can be added in any CMS, and just as easily by an AI that wasn't told to leave them out.

That matters more every month, because more sites are now written by AI tools. Among new German companies in 2026, 2.5% of websites carried a clear AI-builder fingerprint and up to 15% were modern code in the style AI tools write (our study of 1,536 new companies, more in how many small-business sites are built with AI). Among established small businesses it is rarer still: of 2,538 websites in 16 cities in Germany, Austria and Switzerland, 0.4% were made with an AI site builder and at most 3.1% look AI-written. An AI builds exactly as fast a site as its brief asks for.

Key takeaways

• The bar: Largest Contentful Paint (LCP) of 2.5 seconds or less for at least 75% of visits. Above 4 seconds is poor.
• The typical small-business site misses it: median LCP 7.1 seconds and a median mobile PageSpeed score of 64 in our 2026 sample.
• It's not the JavaScript: median Total Blocking Time was only 17 milliseconds. The delay is the first big element and what loads before it.
• The usual suspects were slower: sites with a tag manager or tracking pixel had a median LCP of 11.0 seconds, against 6.4 seconds without.
• With AI, speed is a brief: put a budget and a handful of rules in the prompt or in CLAUDE.md, then check the result in PageSpeed Insights.

What "fast" means: the numbers Google uses

Google measures speed with three Core Web Vitals. The targets below come from web.dev, Google's own documentation, and apply to the 75th percentile of page loads, split by mobile and desktop.

The PageSpeed score from 0 to 100 is a separate thing: a Lighthouse lab test. Google rates 90 to 100 as good, 50 to 89 as needs improvement and 0 to 49 as poor. For the mobile test, PageSpeed Insights simulates a mid-tier phone on a mobile network, which is why a site that feels quick on your office desktop can score badly.

What we measured on small-business websites

Before we rebuild a site, we test its homepage with Google PageSpeed Insights, mobile lab test, the same check our free website analyzer runs. The figures below come from more than 130 small-business websites we tested this way in 2026, one measurement per site, mostly WordPress (ShiftPress data, 2026).

The striking number is the last but one. Total Blocking Time measures how long JavaScript keeps the browser busy. At a median of 17 milliseconds it was close to zero, so the typical site wasn't slow because of heavy code running. It was slow because the biggest thing on the first screen took seven seconds to arrive. That points at image size and at everything the browser has to fetch before it gets to that image.

What the slow sites had in common

When our copier reads a site, it notes what's on it: a tag manager, a cookie tool, a page builder, a slider. Put next to the PageSpeed results, a pattern shows up.

Read this as a pattern, not as proof. These things often travel together (a site with a tag manager usually has a cookie tool too), and some groups are small. But the direction is the same in every row, and it matches Google's own LCP guidance: anything that delays the browser from finding and loading the main image makes the page slower.

Weight tells the same story. In our website carbon report, the median homepage of a new company weighed 1.62 MB. A phone on a mobile network needs time for every one of those megabytes.

The checklist, ordered by what moved the numbers

1. Make the first screen light

One hero image, not a slider. Export it at the size it's shown (about 1,600 pixels wide is plenty for a full-width hero), as WebP or AVIF, and compress it. Give the <img> a width and height so nothing jumps, add fetchpriority="high", and never lazy-load it: Google's guidance says lazy-loading the LCP image "will always lead to unnecessary resource load delay". If the hero is a headline on a colour, even better: text is the fastest LCP element there is.

2. Cut third-party scripts, starting with the tag manager

In our data this was the biggest gap: 11.0 against 6.4 seconds. A tag manager is a container that loads more scripts, so it tends to grow. Ask which tools you actually look at. One analytics script, loaded after consent, is enough for most small businesses. Maps, video and social feeds below the fold can show a static preview and load on click.

3. Choose the consent tool with the page in mind

A banner that loads its own framework, fonts and a vendor list before anything else costs time on every visit. Fewer trackers means a smaller banner, and a site that sets no tracking cookies at all needs far less consent machinery. Whether you need a banner is a legal question for your own case, but the speed effect is not.

4. Skip the page builder

Visual page builders wrap every section in layers of extra markup, CSS and scripts. The gap in our data was smaller than for scripts (7.8 against 6.7 seconds), but it's there on every page. When AI writes the site, there is no reason for a builder: plain HTML and CSS is what Claude writes best anyway.

5. Keep fonts to two files

Self-host the fonts (no request to a font service), use woff2, two weights at most, and font-display: swap so text shows immediately in a fallback font.

6. Serve static files from a CDN

A static page is built once and then served as a finished file from servers near the visitor, so the first byte arrives quickly. That's the part where the choice of system really matters, and it's why static sites are a good fit for small businesses (more in static website SEO).

7. Everything below the fold: lazy, sized, light

Images further down get loading="lazy", a width and height, and a srcset so phones don't download desktop sizes. That keeps layout shift low and the first screen free.

Tell Claude: the rules in one block

Claude follows a performance brief well. Without one, it often reaches for big stock images, several font weights and a library or two. Paste this into your first prompt, or into CLAUDE.md if you build in Claude Code, so it applies to every page:

## Performance rules (apply to every page)
    - Budget: LCP under 2.5 s on a mid-range phone, CLS under 0.1,
      homepage under 1 MB in total.
    - Hero: one image or plain text on colour. No slider, no carousel,
      no autoplay video.
    - Hero image: max 1600 px wide, WebP or AVIF, compressed, width and
      height set, fetchpriority="high", never loading="lazy".
    - All other images: loading="lazy", width and height set, srcset
      with a phone and a desktop size.
    - Fonts: self-hosted woff2, max 2 files, font-display: swap.
    - Plain HTML and CSS. No page builder, no UI framework for content
      pages, JavaScript only where a feature needs it.
    - No tag manager. One analytics script, loaded only after consent.
    - Maps, videos and social feeds: static preview, load on click.
    - When done, list each page's total weight and its LCP element.

Design skills make the result look better without breaking these rules; our list of the best Claude skills for web design covers which ones to load, and which Claude model to use covers the model. After each build, run the homepage through PageSpeed Insights on mobile and paste the top findings back to Claude.

So which CMS is fastest?

For a small business, the fastest setup is the one that serves finished static pages and stays out of the way. If you already have a content library, choose a system that can import it without a rebuild, publishes static pages or caches every page completely, and doesn't force a page builder on you. Then test one real page before moving the rest. Our comparison of CMS platforms goes through the options. Just keep the numbers above in mind: none of the slow sites in our sample were slow because of the CMS name in the footer. They were slow because of what was put on the first screen. The quickest version of all this is to let ShiftPress build the first draft and spend your time on the facts only you know.

Frequently asked questions

The bottom line

Fast is a decision you make on the first screen: one light image, few scripts, no builder, static files. The typical small-business site in our data got that wrong and took seven seconds to show its main content. An AI can build you a site that loads in under two and a half, as long as the brief says so.