How Do You Audit Image File Sizes Across a Webflow CMS?

How do you audit image file sizes across a Webflow CMS?

Pull the full asset list from the Webflow Data API, which returns each file's size, sort it from largest to smallest, and match the heavy files to the CMS items and pages that use them. Then fix the images on your highest-traffic templates first, because that is where size costs you real visitors.

Image weight is one of the most common reasons a Webflow site feels slow on mobile, and CMS collections are where it hides. A static page gets reviewed when it is built. A blog post or case study added by a busy marketer at the end of a long week often carries a hero image straight from a design tool or a phone camera.

Over a year, that adds up to hundreds of heavy images that nobody checked. This article walks through how I would audit them in a structured way, without opening every item by hand, and how to decide which fixes are worth the time.

Why do image sizes matter for a Webflow site?

Large images delay the moment a page's main content appears, and that moment is measured by Largest Contentful Paint. Google's web.dev guidance says a good LCP is 2.5 seconds or less, measured at the 75th percentile of page loads across mobile and desktop. Heavy hero images push pages past that line.

The web.dev documentation lists img elements among the element types that can count as the largest contentful element. On most blog posts, case studies, and resource pages, the biggest thing above the fold is an image. If that image is heavy, LCP is slow, and the visitor stares at a half-loaded page.

For a B2B site, this is a go-to-market problem, not just a technical one. The pages that carry the most CMS images are often the ones buyers read during evaluation: case studies, comparison posts, and guides. A slow case study on a phone, opened from a link in a sales email, is a weak first impression at exactly the wrong moment.

How do you get a list of every image and its size?

Use the Webflow Data API's list assets endpoint. Webflow's developer documentation shows that it returns each asset with its content type, size in bytes, and hosted URL, and that it requires the assets:read scope. Paginate through the results and save them to a sheet.

The endpoint is GET /v2/sites/{site_id}/assets, and the documentation shows it accepting offset and limit parameters for pagination. A short script, a Make or n8n workflow, or a Claude Code session can page through the full list and write each asset's name, type, size, and URL into a Google Sheet or an Airtable base.

If you do not want to touch the API, you can still audit manually by opening the Assets panel in the Designer and sorting what you can see. That works for small sites. For a CMS with hundreds of items, the API is faster and gives you a complete picture instead of a sample.

How do you connect heavy images to the pages that use them?

Pull your CMS items too, and match each item's image field URLs against the asset list. That tells you which blog post, case study, or resource page carries each heavy file. A file on a page nobody visits matters far less than one on your most-read article.

The Webflow Data API also lists collection items, and image fields in those items reference hosted asset URLs. Matching on the asset ID or file name in the URL links each heavy image to the item and template that displays it. In a sheet, a simple lookup column does the job.

Once the match exists, add one more column: monthly visits for each page, from Google Analytics 4, Webflow Analyze, or Search Console. Now you can sort by size and traffic together. A two-megabyte image on a page with real traffic jumps to the top. The same image on an archived post from three years ago drops to the bottom. I used a similar join approach in how to audit alt text across a Webflow CMS collection.

What file size should a CMS image be?

There is no universal number, but I use working targets: hero images under about 200 kilobytes, inline content images under about 100 kilobytes, and thumbnails much smaller. Treat these as starting points, not rules. The right size depends on dimensions, format, and where the image sits on the page.

The more useful question is whether an image is larger than it needs to be for how it is displayed. A 4000 pixel wide photo shown in a 1200 pixel wide content column is wasting most of its bytes. A screenshot saved as a large PNG when a compressed format would look identical is the same kind of waste.

I set the thresholds in the sheet as a flag column. Anything over the hero target on a hero field, or over the inline target in a rich text field, gets flagged. That turns a list of hundreds of files into a short list of the ones that are clearly oversized for their job.

How should you fix oversized images?

Resize to the largest size the layout actually displays, compress, and save in a modern format where your setup supports it. Then replace the file in the CMS item. Fix the highest-traffic pages first, and set a rule so new uploads arrive at the right size from the start.

For resizing and compression, tools like Squoosh, TinyPNG, or the export settings in Figma work well. Export at the display width, or around twice that for sharp results on high-density screens, and compress until the quality drop is just noticeable, then step back one notch.

Webflow has its own image handling, including responsive image variants, which the API shows alongside each asset. Check Webflow's help center for the current upload limits and conversion options before changing your process, because those details change over time. Whatever Webflow does automatically, a smaller source file still helps. I covered how Webflow's responsive sizes interact with hero layouts in this piece on Webflow image sizes for adaptive heroes.

How do you check that the fixes actually helped?

Compare LCP before and after on the pages you changed, using field data where you have it. PageSpeed Insights shows lab and field data for a URL, and the Core Web Vitals report in Google Search Console groups pages by status. Field data moves slowly, so give it a few weeks.

Lab tests give you an immediate read. Run PageSpeed Insights on a fixed page before and after replacing the image, and note the LCP time and the LCP element. If the LCP element is still the hero image and the time dropped, the fix worked. If the LCP element changed to something else, the image is no longer the bottleneck, which is also good news.

Field data is the real verdict, because it reflects actual visitors on actual devices. Since web.dev recommends judging LCP at the 75th percentile of page loads, a few fast lab runs are not enough on their own. Check the Search Console report again after a few weeks to see whether the affected page groups moved toward good.

How do you stop heavy images from coming back?

Write a simple upload rule for everyone who edits the CMS, and audit on a schedule. A one-line guideline in the editor's checklist, such as export hero images at a set width and compress before upload, prevents most problems. A quarterly re-run of the audit catches the rest.

The rule only works if it is easy. I like to give editors a ready-made export preset in Figma or a short note pinned where they work, rather than a long style guide. If the right size is the default, people use it. If it takes effort, they skip it on busy days.

Because the audit is built on the API and a sheet, re-running it is cheap. Schedule it in Make or n8n to refresh the asset list monthly and flag any new file over your thresholds. That turns image hygiene from a cleanup project into a small, ongoing check, which is how it should work on a site that publishes regularly.

Is an image audit worth it for a small Webflow site?

For a site with a handful of pages, a quick manual check in the Assets panel is usually enough. The API-based audit pays off once you have a CMS with dozens or hundreds of items, multiple editors, and pages that matter to pipeline. That is when manual checking stops being realistic.

The decision comes down to where your buyers spend time. If your case studies, comparison posts, and guides live in the CMS and get traffic from search, sales emails, and AI answers, slow images on those pages cost you attention at the moment it counts. An afternoon of auditing is a reasonable trade.

If your site is mostly static pages that you built carefully, focus on those pages in PageSpeed Insights instead. The CMS audit is a tool for scale, not a ritual for every site.

What should you do next?

Export your asset list through the Webflow Data API, add a size flag column, and match the flagged files to your CMS items and their traffic. Fix the top ten by traffic first, re-test those pages in PageSpeed Insights, and write a one-line upload rule for editors.

Then schedule the audit to refresh monthly so new heavy images get caught early. The first pass is the most work. Every pass after that takes minutes.

I build Webflow sites and the automations behind them for lead generation, and performance on CMS pages is part of that. If your case studies or guides feel slow on mobile, reach out and let's chat.