Webflow's responsive images help browsers choose an appropriate image size. They do not remove the need to prepare the original image thoughtfully. A poorly cropped photograph, an oversized background, or a screenshot compressed until the text becomes fuzzy still needs a human decision.
That was the core of my advice in the old forum's image optimization discussion: establish a repeatable preparation workflow, then let the platform handle the responsive behavior it supports. The tools have changed since 2019, but the workflow remains useful.
Decide where the image will appear
Before exporting anything, identify the image's job. A full-width hero, a small article card, and a diagram inside a tutorial need different treatment.
Measure the largest practical display size in the layout. If a card is 480 CSS pixels wide, a source around 960 pixels wide is a reasonable starting point for a sharp image on a display with a device pixel ratio of two. It is an example, not a universal target. Check the result in the actual layout and avoid enlarging a small original just to meet a number.
For screen use, pixel dimensions and compression are the useful controls. Changing a file's DPI metadata from 300 to 72 does not, by itself, make the browser download fewer pixels. Crop unwanted content and resize the actual image.
Export for the content, then compare
A photograph can often tolerate more compression than an image containing small text, sharp interface lines, or a logo. Keep your original master so you can produce another version later.
Use a tool such as Squoosh to compare the original and compressed result. Check edges, gradients, skin tones, and text at the intended display size. Reduce quality until you can see the tradeoff, then step back to a version that holds up.
Choose a file-weight target for your own project rather than treating an upload ceiling as a performance budget. Ten images at 300 KB each already add roughly 3 MB before fonts, scripts, and other assets. A small improvement repeated across every card can matter more than squeezing a few extra kilobytes from one logo.
Webflow now also provides an Assets panel compression action that converts JPG and PNG assets to WebP or AVIF. Keep a separate social-sharing image where needed: Webflow's current documentation warns against converting assets used for Open Graph images to those formats.
Understand where responsive variants apply
According to Webflow's responsive-images documentation, direct uploads through the Assets panel or a CMS image field can create responsive variants. The browser uses the image's srcset and sizes information to choose a suitable file.
There are exceptions worth checking before a migration or bulk import:
- Images added through CSV import or the API do not generate those variants through that import path.
- The documented responsive-image feature does not cover background images or images inside rich text elements.
- Interactions can change an image's displayed size after its normal layout has been measured.
Treat these as separate cases in your checklist. An image that looks fine in a CMS field may behave differently when the same file becomes a CSS background. A bulk import deserves its own published-page inspection.
Give backgrounds their own budget
A large background can look excellent on a desktop and still be an expensive download on a phone. If the composition permits it, use an Image element with an appropriate crop and object-fit behavior instead of making every image a background.
When a background is appropriate, prepare it for the display sizes you actually need. Consider a smaller mobile version and check the focal point at each breakpoint. A narrow crop of a wide photograph may need different art direction, not simply another round of compression.
Make uploads predictable for editors
A good handover should answer a few basic questions: what aspect ratio belongs in each field, what dimensions are a sensible starting point, and how should the editor check the result?
For example, document one recipe for article cards and another for hero images. Use clear filenames and meaningful alternative text where the image conveys information. Keep decorative images from adding unnecessary spoken content for screen-reader users.
If you automate preparation, test a small batch first. Check orientation, transparency, color, and filenames before running hundreds of assets through the same settings. Automation is most useful after the recipe is dependable.
Verify the published result
Open a real page on desktop and mobile. In browser developer tools, inspect which image URL actually loads and how many bytes it transfers. Confirm that the crop works, text remains readable, and a hidden or off-screen image is not being mistaken for a performance improvement.
Keep a short before-and-after record for a representative page. The useful result is a lighter page that still communicates clearly. A smaller file alone is not enough if the image no longer does its job.
Where this guide started
Adapted and expanded from Jeff Selser's webdev replies on January 16 and 18, 2019 in “Image Optimization.” Current guidance adds Webflow's format conversion and import exceptions, and clarifies that DPI metadata is not a web performance setting.
