For pixel-based images, we look at the resolution
in terms of width and height. How many pixels wide, and how many pixels
high—or tall. For a lot of projects, we’ll have a photo
or another type of image, and it might have a massive starting resolution because it came
that way out of the camera, or from a graphic designer whose assets won’t even fit on
Dropbox. Let’s start with a vintage display: the
1999 iBook. This laptop display has a width of 800 pixels,
and a height of 600 pixels. And if we wanted to have an image cover the
full width of this display, we’d want to make sure that that image is sized properly. Well...here’s a photo that has a resolution
of 200x150. That'll fit. But when it’s blown up to cover our display
— even a vintage display like this — it looks horrible. That’s because the resolution is far too
low, and when it’s scaled up like this, everything looks blurry. Now from the other side, here’s a different
photo—this time the resolution is 57,600x38,400. If we try to scale that down to an 800x600
display — when we scale that down to fit on our vintage iBook — it looks fine. No distortion. But we now have another less visible (or even
invisible) problem: If we assume for a second that the iBook display
here is the largest display we’re going to use for this image, then we’re wasting
all this resolution. And the reason that could be a challenge is
that because there’s all this extra resolution—all this extra data, we’re left with a file
size that’s inefficient. And ridiculous. The file is 7.8 gigabytes in size. Besides the fact that the iBook doesn’t
even have a hard drive big enough to hold the file, its built-in 56k modem would take
over two weeks to download the image over AOL. If low resolution files look bad when scaled
up, and high resolution files can be too large and too slow, what are the best practices
for image resolution in our projects? Whether we’re designing for a device from
1999 or a more modern device, there are two major types of images we work with in our
projects: inline images, and background images. If it’s an inline image that you drop into
your project as an actual Image Element, Webflow is automatically going to take care of this
for you. It’ll create variants of this image at different
sizes—different resolutions. And when a user loads up that page, the browser
serves the best image based on that user’s screen size and their resolution. So on the iBook, a lower-resolution, smaller
image will get pushed to that display. And it’ll look great. And if it’s a Surface Studio, a higher-resolution,
larger image will load on that device. That’s inline images. But if it’s a background image, if we’re
setting the background on a particular element of our project— like a section— we’ll
want to optimize our image—we’ll want to figure out the right resolution. Sometimes the best route is to design for
the most common, practical displays. Always considering your audience. The 15-inch MacBook Pro, for instance, has
a resolution of 2,880 x 1,800. You could look at devices like that and choose
a width of around 3,000 pixels for your image. On a larger display, it’ll scale up and
still look great. Also, in image editors like Photoshop, we
can adjust the quality of formats like JPEG to add some compression and reduce our file
size. In this case, we can drop the quality down
while making sure we’re not getting a visually crusty image. And if we do, we can crank it back up until
it looks right. So, inline images automatically get scaled
for us. Just upload a larger resolution and Webflow
takes care of the rest. And Background images? We’re always considering the displays we’re
designing for. And those are some of the considerations we
want to make when we’re optimizing images for our projects.
