Preload and preconnect are resource hints: short instructions in a page’s HTML that tell the browser to start fetching something, or to open a connection to another server, earlier than it otherwise would. Used carefully, they make the main content of a page appear sooner. Used carelessly, they slow it down.
How preload and preconnect work
A browser normally discovers files in the order it reads them. Fonts referenced deep inside a stylesheet, or a hero image set as a CSS background, are found late, so they start downloading late. A preload hint, written as a link element with rel="preload" and an as attribute saying what the file is (for example as="font" or as="image"), tells the browser to fetch that file immediately and at high priority, because the page will definitely need it.
Preconnect works one step earlier. Fetching anything from another domain, such as a font service, a CDN or a payment provider, needs a DNS lookup, a network connection and a secure TLS handshake before the first byte arrives. On a mobile connection that can add a noticeable delay. A link element with rel="preconnect" pointing at that origin tells the browser to do the setup work straight away, so the later request starts instantly. A lighter relative, dns-prefetch, only does the DNS lookup and is a reasonable fallback for less critical origins.
Two details catch people out. Fonts must be preloaded with the crossorigin attribute, even when they are on your own domain, or the browser fetches them twice. And modern browsers also support fetchpriority="high" on an image, which is often a simpler way to prioritise the main image than preloading it.
Why it matters for a UK business
These hints mostly affect Largest Contentful Paint, the Core Web Vitals measure of how quickly the main content appears. Many UK small business sites run on WordPress, Shopify or Squarespace themes with a large hero image, custom fonts and several third-party scripts. On a mid-range phone on a busy train line, the difference between the hero image starting at once and starting after the stylesheet has loaded can be the difference between a page that feels instant and one that feels broken.
Page experience is a modest ranking consideration compared with relevance and content quality, so do not expect preloading to lift rankings by itself. The commercial case is that faster pages lose fewer visitors before they see your offer.
Common mistakes
- Preloading too many files. Everything marked urgent means nothing is, and the files compete for bandwidth with the ones that matter.
- Preloading files the page does not use, which wastes data. Chrome warns about unused preloads in the developer console.
- Leaving out crossorigin on font preloads, causing a double download.
- Preloading an image that is lazy-loaded or below the fold.
- Preconnecting to every third-party domain. Each connection costs resources, so keep it to the few origins needed in the first moments of loading.
- Stacking hints from a theme, a speed plugin and a CDN without checking what the final HTML contains.
How to act on it
Run your key pages through PageSpeed Insights and look at what it identifies as the LCP element. If it is an image or text that waits for a late-discovered file, that file is a candidate for a preload or fetchpriority hint. Check the field data at the top of the report, which reflects real visitors, not just the lab test.
Next, list the third-party origins your page contacts early, such as a font provider or a CDN, and preconnect only to the one or two that block visible content. Look at the waterfall in your browser’s network panel before and after each change, and remove any hint that does not improve it. Pair this with critical CSS and sensible lazy loading below the fold. If you want speed work done as part of a wider fix of crawling and performance, my technical SEO service covers it.