Resizing changes pixels; compression changes bytes per pixel
Resizing throws away pixels — a 4000px image becomes 2000px. Compression keeps every pixel and stores each less precisely. Both shrink the file; only one changes how large the image can be displayed.
Resizing is the stronger lever
File size scales with pixel count, so halving both edges quarters the data before compression even starts. Dropping quality from 85 to 70 might save 30%; halving the dimensions saves around 75%.
Resize first, then compress
Always downscale to the size the image will actually be displayed at before encoding. Compressing a 4000px image and then letting the browser shrink it to 800px wastes bandwidth and looks worse than doing it in the right order.
DPI is metadata, not resolution
DPI only matters for print — it tells a printer how large to render the pixels. On screen it is ignored entirely; a browser cares about pixel dimensions and nothing else. Changing DPI without resampling changes no pixels and no file size.
WebP's dimension ceiling
Neither edge can exceed 16383 pixels — a property of the WebP bitstream itself. Panoramas and high-DPI scans can hit it; oversized images are scaled down proportionally to fit.