#responsive images

From the recent news on AO3:

To make the Archive friendlier for smaller screens, we're updating the default display of images to ensure they won't be any wider than the full width of your screen.

Basically this means all images will automatically resize to fit the size of your screen, no matter if you are viewing a story on a smart phone, tablet/pad, or 2400x1980 computer screen.

Example:

I made a tutorial back in 2018 describing how to make images responsive in AO3 works, and even though that tutorial is now irrelevant, I’ve never been happier. This means less work for me, too. I’m ecstatic.

No more horizontal scrolling, no more tinkering with HTML, no having to create work skins with responsive CSS coding and then having to write the attribute in for each image you use--it’s all automatically done for you.

And if authors/artists want their readers to be able to view the big huge full-sized image, there are instructions provided in the article to do that.

Next.js Images That Sell: Faster Pages, Sharper Photos, Fewer Lost Customers How to serve responsive images for ecommerce and portfolios without the tech headache

Explore more from Prateeksha Web Design: - Home: https://prateeksha.com - Blog: https://prateeksha.com/blog - Original post: https://prateeksha.com/blog/nextjs-image-optimization-responsive-ecommerce-portfolio

Intro

Images sell your products and show off your work — but they’re also the most common reason pages load slowly. Slow images mean lower conversion, frustrated visitors, and worse search ranking. The good news: you don’t need to be an engineer to make big improvements. With a few practical habits — reserving layout space, serving the right size and file type to each device, and prioritizing the single hero image — you’ll cut load times, stop layout jumps, and keep images crisp. This guide gives a simple playbook you can follow (using Next.js tools or equivalent CDNs) so your shop or portfolio feels fast on phones and looks great on big screens.

Where most people go wrong

Treating every image the same: uploading giant originals and letting the browser downscale them wastes bandwidth.

Not reserving space: images without set dimensions cause layout shifts and make pages feel janky.

Preloading everything: marking many images as “priority” competes for bandwidth and hurts the most important image.

Main framework — 5 simple steps

Measure first - Run Lighthouse or WebPageTest to find the Largest Contentful Paint (LCP) image and the biggest offenders. - Tip: focus on pages that drive sales or portfolio views.

Reserve layout space - Always provide width/height or use aspect-ratio boxes so images don’t shift content when they load. - Tip: this single change dramatically reduces Cumulative Layout Shift (CLS).

Serve the right size and format - Use responsive images (srcset/sizes or your image tool) so mobile devices get smaller files and desktops get sharper ones. - Prefer modern formats (WebP/AVIF) where supported; fall back to JPEG/PNG for older browsers. - Tip: thumbnails can use lower quality (50–65), hero images higher (75–90).

Prioritize and lazy-load - Mark only the main hero image as “priority” so it preloads; lazy-load thumbnails and offscreen images. - Tip: use small blurred placeholders for a smoother perceived load.

Use edge delivery and caching - Offload transforms to an image CDN or let your platform cache optimized images at the edge. - Version or hash files to allow long cache times without invalidation headaches. - Tip: if you have thousands of SKUs, a CDN with on-demand transforms saves CPU and storage.

Short case study

A small ecommerce site had a 1.6MB hero JPEG and an LCP of ~3.8s on mobile. Changes made: - Added width/height, set sizes to match layout, set hero to priority, reduced quality to 80, and enabled WebP where possible. Result: LCP dropped to ~1.6s in lab tests; hero transfer size fell to ~280KB for modern browsers. Conversion tests showed improved engagement on mobile.

FAQs

Do I need Next.js to do this?

No. Next.js includes convenient helpers, but the principles (reserve space, responsive sizes, modern formats, CDNs) apply to any stack.

Should every image be AVIF or WebP?

Serve them when the client supports them. Use fallbacks for older browsers. CDNs/optimizers typically negotiate formats automatically.

How many sizes should I generate?

A small, pragmatic set tied to your breakpoints (mobile, tablet, desktop) avoids too many files and keeps caching efficient.

What about build-time vs runtime conversion?

Build-time pre-generation gives no runtime cost but uses storage and build time. Runtime/CDN on-demand saves storage but watch for initial encode latency.

Conclusion + quick checklist

Reserve layout space (width/height or aspect-ratio).

Serve responsive sizes and modern formats; tune quality per context.

Prioritize the single LCP image and lazy-load the rest.

Use an image-aware CDN or cache-optimized platform for scale.

Since AO3 is no longer adding new user-created skins to their list of public skins, and with all the fics and ficart that are being posted for the @thorkibigbang going on, I thought I’d share this little trick. 

Okay, so you’ve got this great image you want to embed into your story on AO3. The only problem is it’s kind of a big image and you can only see part of it on your device (or you have to scroll horizontally in your browser to see the whole thing). And your readers are viewing it on screens of varying sizes, so you know they’re probably going to have some difficulties looking at it.

Not anymore! This trick will make it so that no matter your screen resolution or window size, your image will always fit nicely in the story and not overflow. These types of images are called “responsive images”, because they automatically respond and adjust to your screen size.

Anyone can use this code and it’s really simple to implement, no knowledge of HTML/CSS necessary. It makes viewing stories with images (especially large ones) on AO3 much easier, and your readers will really appreciate it.

Here’s all you have to do:

1) Log into your AO3 account. On your Dashboard, click the Skins link.

2) Click the My Work Skins button on the resulting page. Then click the Create Work Skin button on the following page.

3) You are now on the Create New Site Skin page (pictured below). Make sure the Type field is set to “Work Skin”. Fill in the Title field with something easy to recognize. This is the Work Skin you’ll be using on any stories where you want to have responsive images.

4) In the CSS box, insert this code:

#workskin .responsive { max-width: 100%; height: auto; }

5) Click the Submit button.

You now have a new Work Skin that will enable you to have responsive images! The magic is all in that one little word, responsive. Now all you have to do is apply it to you story. Here’s how:

6) Navigate to the story you’d like to use this code in. Click the Edit button.

7) Select your responsive work skin from the drop down menu in the Select Work Skin section. You will do this for every story in which you want to use this trick.

8) In the Work Text section on the same page, select HTML if it is not already on. The general, no-frills code for inserting an image typically looks like this: 

<img src=“http://www.yourdomain.com/yourimage.jpg” />. 

All you’ve got to do is add some “class” and the magic word. Like this:

By adding the class=“responsive” tag to this line of code, you’ve made the image responsive. (Remember to mind your spaces, otherwise the code may not work.)

9) Click Save and you’re done! Go and enjoy your nice, neat, responsive ficart. Just remember to select this Work Skin for every story you wish to use it on, and use the corresponding HTML code in your Work Text.

The responsive technology is becoming more and more important as the mobile devices are popular nowadays. How do we responsive correctly?

Imperfect solution only using CSS

We only add two simple line decorations to responsive images in the traditional way.

img { max-width: 100%; height: auto; }

The images will fit all the devices viewport with the code below. But how about the image size?…