High bandwidth usage for static site built on Next.js, hosted on Vercel, using Sanity.io for image assets.
13 replies
Last updated: Mar 5, 2021
Can someone explain to me how my bandwidth can be so incredibly high for a static site that is only using roughly a dozen images?? This site has been live for 9 days and the bandwidth spike seems absolutely wild for what this site is:
Feb 9, 2021, 6:00 PM
Not sure what the cause of the usage is but last month someone did find a work around that really cutback bandwidth: https://sanity-io-land.slack.com/archives/C9Z7RC3V1/p1610183363450900
Feb 9, 2021, 6:06 PM
G
Hi User. That is indeed a lot of bandwidth usage. It looks like the bandwidth really declined over the weekend so I’d be curious to know how your studio is configured (whether you’re using previews, etc.).
Feb 9, 2021, 6:27 PM
Thanks
user M
- the cloudfront solution is interesting, but I don't love the idea of introducing yet another service to manage, and have the client pay for, for something I feel should be already be happening at the sanity level.Feb 9, 2021, 9:00 PM
user A
yea, what info can I provide about my studio that would help give you insight? There is a preview option within the studio for pages, but I honestly don't believe the client has really leveraged that since we built out the current content together before launch. Since the spike in bandwidth was after launch, I'd highly doubt that would be causing it?Feb 9, 2021, 9:32 PM
G
I see what you’re saying, and hopefully one of Sanity’s engineers can give you some insight (I’ve put in a request for you). The thing that stood out to me was that bandwidth usage seemed to really drop off over the weekend, which leads me to believe it’s something happening in the Studio from Monday-Friday (when I assume your clients are working in it). Perhaps some details about your stack (Next.js, Gatsby, 11ty, etc.) and tech used (SWR, ISR, etc.) could offer an ah-ha moment.
If it’s the site I think it is, everything looks efficient on the front end (images are optimized, etc.) so I imagine anything going too crazy there would be clear in your analytics. I hope this can be figured out for you quickly!
If it’s the site I think it is, everything looks efficient on the front end (images are optimized, etc.) so I imagine anything going too crazy there would be clear in your analytics. I hope this can be figured out for you quickly!
Feb 9, 2021, 9:41 PM
Thanks so much
https://cotemiami.com/ • Built on Next.js, hosted on Vercel
• Image assets are using the sanity image-builder: @sanity/image-url
• sanity client has
user A
! Here's some more info about the site:• Site in question: https://cotemiami.com/ • Built on Next.js, hosted on Vercel
• Image assets are using the sanity image-builder: @sanity/image-url
• sanity client has
useCdnflag set to true in production (only turned off for dev or preview mode)• None of the pages are server-side rendered, all are SSG
Feb 9, 2021, 9:53 PM
G
Ahh, okay. That’s a different one than I thought so I’m glad you clarified. I got a bit over 20MB of transfer when visiting the home page. Is that rendering in the Studio preview?
Feb 9, 2021, 10:06 PM
user A
thanks! And nah the rendering and other video loop at the top is loading static from the project (so should be hitting bandwidth on the Vercel side of things)Feb 9, 2021, 10:50 PM
I figured allowing video upload on the sanity side of things would be a surefire way to balloon the bandwidth, so I kept it out of there (and really, they should be on Vimeo if I wanted to avoid bandwidth usage on Vercel too)
Feb 9, 2021, 10:51 PM
G
DM me the project ID and I can have operations look into it?
Feb 10, 2021, 8:12 AM
R
Hi User, I checked out some logs and it seems like the main culprits for high bandwidth are:• Large PDFs such as menus (up to 3 MB per request)
•
• Current image URL -
https://cdn.sanity.io/images/1je3os9g/production/e0e3bf999e269cc88da404d9adf72e68d80c689a-801x1202.jpg?w=1200&fm=webp&q=100 (inflated size + q=100) = 1.2 MB• Optimised image URL -
https://cdn.sanity.io/images/1je3os9g/production/e0e3bf999e269cc88da404d9adf72e68d80c689a-801x1202.jpg?fm=webp&q=80 (original size + q=80) = 281 KBHope this helps!
•
q=100quality parameters in images, which probably inflates file size without improving image quality vs something like
q=80. I think this alone could lead to a reduction of ~30% in bandwidth•
w=1200or
w=800on images that are shown at a smaller size or have originals that are smaller than the defined size. Optimising these will probably deliver additional savingsAn example of the last point is the attached area on the home page, but it also occurs in larger images:
• Current image URL -
https://cdn.sanity.io/images/1je3os9g/production/e0e3bf999e269cc88da404d9adf72e68d80c689a-801x1202.jpg?w=1200&fm=webp&q=100 (inflated size + q=100) = 1.2 MB• Optimised image URL -
https://cdn.sanity.io/images/1je3os9g/production/e0e3bf999e269cc88da404d9adf72e68d80c689a-801x1202.jpg?fm=webp&q=80 (original size + q=80) = 281 KBHope this helps!
Feb 10, 2021, 11:09 AM
G
Interesting, thanks
user A
and user M
! I'll let them know about the PDFs, didn't even think to check those out, but I agree those are massive (and probably what visitors are looking at most). The image inflation is also a good catch. I appreciate the insight on all of this! 🙌Feb 10, 2021, 4:25 PM
P
Hy User,I'm having similar bandwidth problems with a site that is built on the same stack (sanity, next.js, vercel) and I wanted to ask, if you were able to resolve your problem? (and if yes, how?) Best regards
User
User
Mar 5, 2021, 2:24 PM
Sanity– build remarkable experiences at scale
Sanity is a modern headless CMS that treats content as data to power your digital business. Free to get started, and pay-as-you-go on all plans.