Slow image loading

Info

Site info:

Having performance issues with my new VuePress static rendered site.

It’s a VuePress site, and it:

  • builds folders and html pages
  • compiles and minifies all scripts
  • copies all images to a single folder (/assets/img/)

Images

I’m seeing slow image loading; images may take 1 - 2 seconds to load; you can see them drawing in as the page loads.

Looking at the Network panel in dev tools shows 2 or sometimes even 3 copies of the same image being loaded; 1 from cloudfront and 2 from the site URL.

i.e.:

Here’s an example of one being downloaded four times! But is only on the page once:

EDIT: I’ve checked my local build and it is also showing the issue of multiple images, so I will jump on the VuePress support channel and ask what is going on there…

I’ve optimised some of them using Tiny PNG but not all, mainly because looking through the site deploy panel, there is the option to optimize assets:

FWIW I’m not sure if this option is actually doing anything; I can see large local images which are now on the server at exactly the same file size.

Haven’t seen this on Netlify before, so unsure what to do. It normally “just works”, though I suppose as this is a portfolio site, it naturally has more images than most sites I have hosted on Netlify before.

DNS

Additionally, I’m not sure if there are DNS issues – I know slow speeds can be associated with that.

My Host is pointing at Netlify using an A record. My hosting company TSO said they don’t do ALIAS but can set up a CNAME record which they say is the same.

I really want to do whatever I need to make this site blazing fast. Happy to change domain registrar if needs be.

So the the multiple image loading seems to be a result of not having a “prefetch” configuration, and VuePress is defaulting to prefetching everything.

Here’s what I found out:

I’ve configured to prefetch only important assets like so:

// .vuepress/config.js
module.exports = {
  ...
  shouldPrefetch (file, type) {
    return type === 'script' || type === 'style' || type === 'font'
  },
}

However, it still seems to be downloading two sets of assets:

A slow, local one, and a fast CDN one.

Seeing as these image paths are baked into the app, do I need to do something special to instead get the CDN image paths in there?

OK, so the “two images” things appears to be:

  1. the URL in the HTML will show a cloudfront URL
  2. the URL in the DevTools will show a local /assets/img/... URL

So I presume VuePress is replacing the original image (which I presume Netlify will have also replaced) ?

I don’t know enough about how Netlify’s magic works to know what is going on here.

So I think I have got to the bottom of what is happening, but not 100% sure what to do about it.

My latest thinking is that is the issue is nothing to do with the CDN per-se , but somewhere between how Vue stores image paths and how Netlify converts them to CDN URLs.

Consider the following:

  • A markdown page lists gallery image assets as an array in frontmatter:
    ./image-1.png, ./image-2.png, …

  • The page component determines the absolute image path:
    require(page folder path + image path)
    /blog/article/image-1.png, etc

  • The build copies all require()ed assets to a final folder, and generates final HTML:
    <img src=”/assets/img/image-1.76sgf4j43f.png”>

  • Netlify swaps out local image src values for CDN src values:
    http://cloudfront....image-1. 76sgf4j43f.png

When the app is running, it has no way to know what the final CDN URL of each image should be, so it loads the local image instead.

Here’s a page which should demonstrate the issue:

If you look at:

  • the source, you can see the the cloudfront URLs
  • the DevTools panel, you see the built asset URLs
  • the JavaScript (click tidy) you see the local asset paths

Is this a common problem?

I currently use a build step which injects images sizes into these arrays, but are there any solutions for paths; can I get the CDN URL at build time?

Hey there, @davestewart !

These are great questions. For this thread, please continue working in the Helpdesk as Scott is assisting you there already! Thank you :slight_smile:

1 Like