Most often the answer is images. A clean-looking page can still ship several megabytes of photos behind the scenes. Images are usually the heaviest thing a browser has to download, so a simple design with unoptimized pictures will still feel slow, especially on a phone with a weaker connection.
We see this on almost every site we are asked to rescue. The layout is fine. The code is fine. Then we open the network tab and find a hero photo weighing four megabytes, exported straight from a design tool at full resolution. One image, and the whole page crawls.
The good news is that image optimization is the highest-return fix in web performance. It is mostly mechanical, it rarely touches your design, and it can cut load time dramatically. Let's walk through how we approach it in 2026.
Images matter because they are the biggest single part of most pages. According to HTTP Archive's Web Almanac, images make up roughly half of the total bytes on the median web page. When one category is that large, shrinking it moves your load time more than any other change you can make.
Weight turns into time. Every extra megabyte is more data the browser must fetch, decode, and paint before the reader sees a finished page. On fast office broadband the delay hides. On a mid-range phone over mobile data, which is how much of your audience actually browses, a heavy image is the difference between instant and sluggish.
This is why we start performance work with images before anything clever. You can tune code all day, but if the hero photo is four megabytes, none of it shows. Fix the heaviest thing first. We take the same order of operations in our guide to improving Webflow PageSpeed.
In 2026 the best default is AVIF, with WebP as the fallback and JPEG as the last resort. AVIF gives the smallest files at good quality, WebP is nearly as small and slightly more compatible, and both beat the old JPEG and PNG formats by a wide margin.
Browser support is no longer the blocker it once was. As of early 2026, caniuse data puts WebP support above 96% of browsers and AVIF near 95%. That means you can serve modern formats to almost everyone and quietly fall back to JPEG for the rare old browser. There is little reason to ship raw JPEGs as your primary format anymore.
Formats still have jobs. We reach for AVIF or WebP on photos, SVG on logos and icons because it stays sharp at any size and weighs almost nothing, and PNG only when we truly need lossless detail or transparency that SVG cannot handle. Picking the right format per image is half the win.
The savings are large. Google's own documentation reports that WebP lossy images run about 25% to 34% smaller than equivalent JPEGs. AVIF goes further and often lands near half the size of a JPEG at similar quality in comparison tests. On a photo-heavy page those cuts add up fast.
Picture a hero image that starts as a two-megabyte JPEG. Converted to a well-tuned AVIF, it might drop to under 500 kilobytes with no visible loss. Multiply that across every photo on the page and you can shed several megabytes without a single design change. That is why format choice is the first lever we pull.
The trade-off is encoding time and tooling. AVIF takes longer to compress, and not every platform generates it automatically yet. In our experience the payoff is worth the small extra setup, because the reader gets a much lighter page and you never have to think about it again once the pipeline is in place.
You serve the right size using responsive images, where the browser picks from several versions based on the screen. The srcset and sizes attributes let you offer, say, a small, medium, and large copy of the same photo, and the device downloads only the one it needs.
This matters because a phone does not need a two-thousand-pixel-wide image built for a desktop monitor. Without responsive images, that phone downloads the giant version anyway and then shrinks it, wasting data and time. With srcset, it grabs a small copy sized for its screen and loads far faster.
Most modern builders, Webflow included, generate responsive image sets for you when you upload through the CMS or designer. We still check the output, because a wrong setting can ship full-size images regardless. The tool helps, but a human should confirm the browser is really getting the smaller files.
Lazy loading tells the browser to wait and load images only as they are about to scroll into view. It saves bandwidth and speeds up the first paint, because the browser no longer downloads pictures far down the page before the reader ever reaches them.
It is simple to turn on. The loading attribute set to "lazy" is built into HTML and needs no extra script. We apply it to everything below the fold: gallery shots, footer logos, images buried deep in a long article. The browser handles the timing, and the page above the fold appears sooner.
The one rule we never break is to skip lazy loading on the main hero image. That image is usually your Largest Contentful Paint element, the thing that should appear first. Delaying it hurts the very metric you are trying to improve. Load the hero eagerly, lazy load the rest.
Images sit at the center of two of the three Core Web Vitals. A heavy hero drags down Largest Contentful Paint, and an image without set dimensions can shift the layout and hurt Cumulative Layout Shift. Get images right and two of your three scores usually improve at once.
Largest Contentful Paint measures how long until the biggest visible element loads, and on most pages that element is an image. A lighter, properly sized hero in a modern format is the most direct way to pull that number down. This is why image work and Core Web Vitals work are really the same project.
Layout shift is the quieter problem. When an image has no width and height set, the browser does not reserve space, so text jumps as the picture loads. Always declaring dimensions fixes it. We dig into all three metrics in our post on Core Web Vitals and SEO, since these scores now feed both rankings and AI citations.
You compress well by matching the effort to the image and checking the result with your eyes, not just a number. Most photos look identical to viewers at a quality setting well below the maximum, so you can cut file size hard before anyone notices a difference.
Our habit is to export at a sensible quality, convert to AVIF or WebP, then compare the small version against the original at real screen size. If it looks the same, we ship it. If we spot banding or blur, we step the quality back up. This takes seconds per image and protects both speed and craft.
Resolution is the other half. There is no point serving a four-thousand-pixel image into a container that is eight hundred pixels wide. We resize to the largest size an image will actually be displayed at, then let responsive images handle the smaller screens. Right format, right quality, right dimensions, in that order.
We lean on a small set of reliable tools. Squoosh, from the Google Chrome team, is great for hand-tuning a single image and previewing formats side by side. ImageOptim strips hidden metadata and squeezes files further. For whole sites, a CDN like Cloudflare can convert and resize images on the fly.
Automation is the goal. Doing this by hand for one hero is fine, but a content-heavy site needs a pipeline that optimizes every upload without a person in the loop. Webflow handles much of this natively, and image CDNs fill the gaps by serving the best format each browser supports, automatically.
Whatever the stack, the test is the same. Open the page, watch the network tab, and confirm the browser is downloading small, modern-format images sized for the screen. Tools make it easier, but the proof is always in what actually loads for a real visitor on a real device.
Start with your heaviest, most visible image, usually the homepage hero. Convert it to AVIF or WebP, size it to its real display width, set its dimensions, and load it eagerly. That single fix often produces the biggest, most obvious speed win on the whole site.
From there, work outward: add responsive sizes, lazy load everything below the fold, and put an automated pipeline in place so new uploads are optimized without thought. None of this changes your design. It just makes the same design arrive faster, which readers and search engines both reward.
If your site feels slow and you suspect images are the culprit, we're happy to take a look and tell you exactly where the weight is hiding. Reach out at phoenix.studio and we will walk through it with you.
Tell us where you want to go. We'll tell you how we'd get you there.