Setting up preloading and prefetching in a website

Preloading and prefetching are techniques you use to make a Web site faster and more fluid. By pre-loading certain resources (even before the user needs them), you reduce the loading time of crucial components. In this article, I explain what the difference is, when to use them and how to set them up technically.

What is the difference?

Preload

You tell the browser: “Load this file as soon as possible, it’s important.”

Commonly used for: fonts, important images, CSS or JS that are needed immediately.

Prefetch

You say to the browser: “This resource might come in handy later, load it in the background already.”

Commonly used for: next pages, external scripts, API calls.

1. Setting Preloading

Preload you add in the of your HTML. You specify what you are loading and what kind of file it is.

Example: preloading fonts

html
<link rel="preload" href="/fonts/inter.woff2" as="font" type="font/woff2" crossorigin="anonymous">
Copy to Clipboard

Example: critical CSS

html
<link rel="preload" href="/css/critical.css" as="style">
Copy to Clipboard

Make sure you set as correctly, otherwise the browser will ignore the preload.

2. Setting Prefetch

Prefetch works especially well for resources that are likely to be needed, but not immediately. Think of a link to a next page or a script that won’t load until later.

Example: a page prefetch

html
<link rel="prefetch" href="/volgende-pagina.html" as="document">
Copy to Clipboard

Or with frameworks like Next.js:

Many frameworks support automatic prefetching of internal routes (client-side routing). But manual prefetching can also be useful for external APIs or third-party scripts.

Aan de slag met SEO? Neem gerust contact op.

Senior SEO-specialist






    3. Also useful: dns-prefetch and preconnect

    For external sources (such as CDNs or external scripts), it is smart to set up DNS resolution and connections in advance.

    Example: Google Fonts

    html
    <link rel="preconnect" href="https://fonts.googleapis.com" crossorigin>
    <link rel="dns-prefetch" href="https://fonts.googleapis.com">
    Copy to Clipboard

    Explanation:

    • dns-prefetch: resolves the domain before it is used
    • preconnect: already connects (TCP handshake, TLS), faster than dns-prefetch

    Use this only for domains you actually use – otherwise you lose performance.

    4. Testing and validation

    Make sure you set preloading and prefetching properly. Incorrect implementation can actually cause delays.

    Tools:

    • WebPageTest: check if preload is working as intended
    • Lighthouse: gives preload recommendations
    • Browser devtools (Network tab): see if a file has been loaded before?

    Best practices

    • Use preload only for critical resources – otherwise you slow down other resources
    • Combine preload with a fallback (e.g.
    • Put preconnect on only what you really need
    • Test load time before and after implementation

    In conclusion

    Preloading and prefetching are relatively simple techniques for making a site faster and smoother. Especially for websites with lots of media, fonts or JS components, you can make noticeable gains with these – if applied properly.

    Senior SEO-specialist

    Ralf van Veen

    Senior SEO-specialist
    Five stars
    My clients give me a 5.0 on Google out of 85 reviews

    I have been working for 12 years as an independent SEO specialist for companies (in the Netherlands and abroad) that want to rank higher in Google in a sustainable manner. During this period I have consulted A-brands, set up large-scale international SEO campaigns and coached global development teams in the field of search engine optimization.

    With this broad experience within SEO, I have developed the SEO course and helped hundreds of companies with improved findability in Google in a sustainable and transparent way. For this you can consult my portfolio, references and collaborations.

    This article was originally published on 16 May 2025. The last update of this article was on 21 July 2025. The content of this page was written and approved by Ralf van Veen. Learn more about the creation of my articles in my editorial guidelines.