π£ 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
-
Here is a gif
0 -
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?
0 -
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/
0 -
Thanks @Gonzalo Rosso Is there a way to add a custom image CDN?
0 -
@JMS do you mean using a custom CDN to serve your images? In that case, setting a custom CDN is not possible now.
0 -
@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 π
0 -
@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
, withwidth=9000
andheight=6000
. When you want to getimage.jpg
, you're actually requesting a version that's optimized for your device (which is downscaled for performance).The actual flow is like this:
- Navigate to the page containing
image.jpg
. - Fetch image
image.jpg
withwidth=1000
. - This ends up fetching the image with url suffix like this
image.jpg?width=1000
. - This image doesn't exist and is generated on the fly.
- 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.
0 - Navigate to the page containing