πŸ“£ The forum has moved to GitHub

We’ve switched to GitHub Discussions as the hub for our community. This will improve the experience of collaborating for everyone, sharing what you’re working on, and discussing ideas for how Swell can be improved. Existing threads will remain open, but new posts are disabled.

Go to GitHub β†’

Slow image loading on schema.io domain

I have noticed that images pop-in on the swell Origin theme. If you load the image in directly via URL it can be somewhat fast 50ms or so, but while browsing the site, images pop-in after close to 1000ms or so.

I have other Next sites in development and they are all fast even with SSR.

I even deployed the site to Netlify to see if this would improve the image performance which it didn't.

Does your team notice this performance issue?

See an image example here...


Answers

  • I tested Swell's demo site and found that it was very fast. Is the Origin theme defaulted to development mode? Is there something I need to do to enable SSG?


    https://origin-demo.swell.store/the-academy/

  • Hi @JMS

    Our team is constantly monitoring these timings, and we haven't found problems so far.

    To see how our services are working, you can check https://status.swell.store/

  • Thanks @Gonzalo Rosso Is there a way to add a custom image CDN?

  • @JMS do you mean using a custom CDN to serve your images? In that case, setting a custom CDN is not possible now.

  • @Gonzalo Rosso Yes, that is what I was looking for. I might try to use nuxt-image and have all the images sent to a different server. Thanks for looking into this πŸ˜€

  • @Gonzalo Rosso your team might be monitoring these requests but it's only going to be evident in tail latencies (let me explain below).

    This issue is related to dynamic generation of optimized images.

    Let's assume the image is image.jpg, with width=9000 and height=6000. When you want to get image.jpg, you're actually requesting a version that's optimized for your device (which is downscaled for performance).

    The actual flow is like this:

    1. Navigate to the page containing image.jpg.
    2. Fetch image image.jpg with width=1000.
    3. This ends up fetching the image with url suffix like this image.jpg?width=1000.
    4. This image doesn't exist and is generated on the fly.
    5. Client has to wait for the image to have finished generating. So, the first fetch for an image is going to have very high latencies. Especially, since judging by the latencies you're using Lambdas to do the image resizing.

    In summary, the first time an image with specific width is requested the end user is going to have to wait for... a long time. I've seen response times on the order of 2 digit seconds. It beats the purpose of having optimized images in the first place.

    Proposed improvement:

    Instead of having the client wait for the image to be generated, the CDN should return the image that is available ASAP. Then in the background generate the downscaled image and upload it to S3. Subsequent requests can then benefit from using the downscaled images, while the initial users don't suffer very high response times.

Sign In or Register to comment.