How to Optimize Images for Web Performance

Open any website performance report and the biggest line item is almost always images. A single blog post hero image straight out of a phone camera can weigh more than the entire HTML, CSS, and JavaScript of the page combined. Multiply that across a homepage with a dozen product photos, and you have a page that takes three or four seconds longer to load than it needs to - on every visit, for every visitor, on every device. The good news is that image optimization is one of the few performance fixes that does not require touching code, hiring a developer, or rebuilding a site. It comes down to four habits: choosing the right format, sizing images correctly, compressing them properly, and loading them in the right order.

None of the steps below require special software. Each one takes a minute or two with a browser-based tool, and the combined effect across a page with ten or fifteen images can be the difference between a three-second load and a one-second load.

Why Images Are the First Place to Look

Images typically account for fifty percent or more of the total bytes a browser downloads to render a page. On an e-commerce category page with twenty product thumbnails, or a blog post with several screenshots, that share can climb even higher. Search engines have built this into how they measure page quality. Largest Contentful Paint, one of Google's three Core Web Vitals, measures how long it takes the largest visible element to render - and on the vast majority of pages, that element is an image. A slow-loading hero image does not just annoy visitors; it directly affects how a page is scored and ranked.

The effect compounds on mobile. A 4 MB hero image that loads in under a second on a fiber connection can take six or seven seconds on a typical 4G connection, and longer still on a weak signal. Every visitor who gives up before that image finishes loading is a visitor who never saw the page at all. Fixing this rarely means removing images - it means making sure every image on the page is no larger than it needs to be.

A quick way to find the worst offenders is to open a page's network requests in browser developer tools, sort by file size, and look at the top of the list. On most sites, the largest five or six files are images, and it is common to find at least one that is several megabytes for no reason - an old hero photo nobody resized, or a screenshot pasted in at full resolution. Fixing just those few files often produces a bigger speed improvement than any other single change available without touching the underlying code.

Match the Format to the Job

Before resizing or compressing anything, the format of the file sets a ceiling on how small it can get. Photographs - product shots, team photos, blog hero images - compress best as JPG or, better, WebP. WebP typically produces files 25 to 35 percent smaller than an equivalent JPG at the same visual quality, and every major browser has supported it since 2020. If a media library is still full of JPGs exported from a phone or camera, converting the ones used on a website is often the single fastest win available, because the savings apply automatically to every page that uses that image.

Graphics with flat colors and sharp edges - logos, icons, screenshots with text, illustrations - behave differently. These compress poorly as JPG because lossy compression introduces visible blur and color banding around hard edges. PNG or lossless WebP preserves the crisp lines these images need while still keeping file sizes reasonable.

The rule of thumb: if it came from a camera, treat it as a photo and lean toward WebP or JPG. If it was made in a design tool and has flat colors or transparency, treat it as a graphic and use PNG or lossless WebP. Getting this one decision right before doing anything else avoids fighting the format for every other optimization step.

Resize to the Size It Will Actually Display At

The single most common image mistake is uploading a file at its original camera resolution and letting the browser scale it down. A modern phone camera produces images around 4000 by 3000 pixels - twelve megapixels - often five to eight megabytes in size. If that image is displayed in a blog post column that is 800 pixels wide, the browser is downloading roughly twenty-five times more pixel data than it can ever show.

The correct approach is to resize the image to match where it will be displayed, with some headroom for high-density (retina) screens. A good rule is to export at roughly twice the display width: an image that will appear in an 800-pixel-wide column should be exported at around 1600 pixels wide. This gives sharp results on retina displays without the overhead of a full camera-resolution file.

This matters even more for responsive layouts where the same image might display at 1200 pixels wide on desktop and 400 pixels wide on mobile. Many sites solve this with multiple image sizes served through the srcset attribute, but even a single correctly sized export, matched to the largest common display width, eliminates most of the waste. Resizing should always happen before compression, since compressing a needlessly large image just produces a needlessly large compressed file. The Image Resizer handles this in one step: drop in a file, set the target width and height, and download the resized version with the aspect ratio locked.

Compress for the Sweet Spot, Not the Smallest File

Compression is where most of the remaining file size disappears, but it is also where people most often go wrong - either skipping it entirely, or cranking quality down so far that images look muddy. For JPG and WebP, quality settings between 75 and 85 percent typically produce files 60 to 80 percent smaller than the uncompressed original, with no difference visible to most viewers at normal screen sizes. Below about 65 percent, compression artifacts - blocky patches around hard edges, blurred fine detail, color banding in skies and gradients - start becoming noticeable.

The best approach is to compress after resizing, using a tool with a live before-and-after preview so the quality drop-off becomes visible for that specific image. A photo with lots of fine texture, like fabric or foliage, may need a slightly higher quality setting than a simple portrait with smooth skin tones and a blurred background. There is no single correct number - the right setting is the lowest one where the difference from the original is genuinely impossible to spot at normal viewing size.

Do Not Forget Favicons and Icons

Favicons are easy to overlook because they are small, but they appear constantly: in browser tabs, bookmark lists, browser history, mobile home screen shortcuts, and increasingly in search results next to a page title. A missing or low-quality favicon makes a site look unfinished, even if everything else is polished.

Modern favicons are not a single file. Browsers and devices request different sizes for different contexts: a 16x16 or 32x32 icon for browser tabs, a 180x180 apple-touch-icon for iOS home screens, and 192x192 or 512x512 icons for Android and progressive web app manifests. Generating each of these by hand from a logo file is tedious and easy to get wrong - a logo with fine detail that looks fine at 512 pixels can turn into an unrecognizable smudge at 16 pixels, so smaller sizes often need a simplified version of the mark. The Favicon Generator takes a single source image and produces the full set of sizes and formats automatically. It is a five-minute task that most websites never quite get around to.

Control When Images Load

Format, size, and compression control how big each image file is. Loading strategy controls when the browser fetches it, which matters just as much for perceived speed. The loading="lazy" attribute tells the browser to delay fetching an image until it is about to scroll into view - ideal for images far down a long page, like the tenth product in a list or an image in the footer.

The opposite applies to whatever image appears largest and highest on the page, often the one Largest Contentful Paint is measuring. That image should load with loading="eager" (the default) and, where supported, fetchpriority="high", so the browser starts downloading it immediately rather than discovering it late after parsing other page content.

A common mistake is applying loading="lazy" to every image on the page, including the hero. This can actually make Largest Contentful Paint worse, because the browser deprioritizes an image it would otherwise have started fetching right away. Lazy loading is for images below the fold; everything visible without scrolling should load as early as possible.

After making changes, it helps to verify the result rather than guess. Free tools such as Google PageSpeed Insights or the Lighthouse panel built into Chrome's developer tools report the exact size of every image, flag ones that are larger than their displayed dimensions, and show the updated Largest Contentful Paint time. Running this check before and after an optimization pass turns a vague sense of "the site feels faster" into a concrete number that can be tracked over time.

A Pre-Publish Checklist

Putting all of this together, a quick pass before publishing any image-heavy page covers five steps:

• Confirm the format matches the content - WebP or JPG for photos, PNG or lossless WebP for graphics and transparency.
• Resize each image to roughly twice its display width, not its original camera resolution.
• Compress to the 75-85 percent quality range and check the before-and-after preview.
• Set loading attributes so only the hero or above-the-fold images load eagerly.
• Make sure the favicon set is complete and not just a stretched logo.

None of these steps require special software or a developer. Page speed is rarely about one big fix - it is about not leaving five small, free improvements on the table for every single image published.