Portfolio·Guide
Resolution vs performance for portfolio images
A hero that looks crisp on your MacBook can look soft on a phone and expensive on a cellular connection. Portfolio delivery is a resolution × device-pixel-ratio × format problem. Get the math once, then let a real media pipeline do the repetitive work.
Delivery basics
What actually decides sharpness on the web
Modern formats first
In 2026, AVIF and WebP are the default delivery lane for photography on the web, not optional enhancements. JPEG remains a compatibility fallback, not the primary export you should hand a CDN.
DPR is why phones look soft
A 375px-wide CSS layout at 2× device pixel ratio is asking for roughly a 750px-wide asset. At 3×, you are closer to 1125px. “Looks sharp on my laptop” never ran that request.
Different surfaces, different budgets
Full-bleed heroes, grid thumbnails, and lightbox full-views need different pixel and byte targets. One export setting cannot honestly serve all three.
EXIF is not copyright
GPS and camera trails are a privacy policy problem, not proof of authorship. Keep color-profile handling intentional. Attribution lives in contracts, notices, and registration.
The 2026 baseline
Generic guides still talk as if WebP were exotic. For photography and high-detail stills, AVIF often lands noticeably smaller than WebP at comparable visual quality; WebP remains the broad modern default when AVIF is unavailable. JPEG is for awkward clients and legacy edges, not for your primary public grid.
On ArtInStack, Cloudflare Image Resizing serves `format=auto` so the edge picks AVIF or WebP from one master, not a folder of hand-exported codec variants. Encoders change year to year; treat “30–50% smaller” claims as directional. What matters for a portfolio is perceptual quality at a byte budget the page can afford.
DPR math, worked once
Layout width is CSS pixels. Sensor sharpness on the device is closer to CSS width × devicePixelRatio. Example: a phone gallery column at 375 CSS px and DPR 2 should be backed by an asset nearer 750 px on the long edge for that slot, not your 2400 px master dumped into every img tag.
That is also why a “retina export” that only exists as one huge JPEG fails twice: it wastes bandwidth on thumbs and still isn’t described to the browser as a responsive set. srcset / sizes (or a platform equivalent) is how the right candidate is chosen.
Portfolio size targets you can actually use
Developer blogs quote one hero number. Portfolios need a small matrix. Use these as planning bands, then let ArtInStack generate variants. Don’t hand-maintain five folders forever.
| Surface | Typical max width | Byte budget (directional) | Notes |
|---|---|---|---|
| Full-bleed hero | ~1600–1920 CSS px (serve 2× candidates as needed) | Often ~80–150 KB with modern codecs | One strong frame; avoid shipping a 4K master to every visitor |
| Grid thumbnail | ~400–800 px asset for common column widths | Tens of KB each when packed well | Many per page; byte budget multiplies fast |
| Lightbox / full view | ~1600–2400 px depending on layout | Higher than thumbs; still not a RAW | Load on demand; don’t preload every lightbox candidate |
Surface-aware delivery (not one export forever)
Dense grids and lightboxes have different cost curves. One “compress to 80% JPEG” setting cannot honestly serve both.
ArtInStack splits the job on purpose: portfolio grids prefer a generated thumbnail (one efficient image per tile) so a 40-image page stays cheap and fast. When a visitor opens a frame, lightbox and photo-detail views pull from your master through Cloudflare Image Resizing (modern formats via `format=auto`, with responsive width candidates). Sharpness shows up where someone is actually looking.
EXIF, GPS, and what photographers worry about
ArtInStack extracts and stores EXIF (including GPS when present) for Media and map features. Public location display is a publication policy (redact or hide per portfolio), not a promise that every CDN derivative silently erases the trail.
Client shoot locations in GPS tags are still a privacy problem for public pages. Decide what visitors should see. Accessibility belongs in alt text you write, not in leftover camera metadata. Copyright is not “whatever EXIF survived the hop.” Put attribution in visible credits, watermarks you chose, and legal terms.
One master, delivery by surface
You upload a master you trust. ArtInStack keeps that master, generates a lightweight thumb for grid scanning, and uses Cloudflare image transformation from the master when a visitor opens the work. Hierarchy on a public page: grid tiles → thumb first; lightbox / photo detail → Cloudflare candidates from the master. You still choose master quality and crop intent. You should not maintain three export folders by hand.
| Surface | What ArtInStack serves | Why |
|---|---|---|
| Portfolio grid | Generated thumb (single efficient image) | Many tiles per page; bytes multiply fast. Avoid a transform per tile by default |
| Lightbox / photo detail | Cloudflare from master (`format=auto` + width candidates) | Someone is looking closely: serve sharpness and modern codecs on demand |
| Your library | Master preserved | Proofing quality stays yours; web delivery is derived, not a silent rewrite of the original |
Good delivery vs fake “optimization”
Good: derive lighter public assets from a master you still own. Bad: a host recompresses your upload into one soft “web JPEG,” calls it optimization, and still ships that same file into every grid cell. That is disk savings dressed as performance. See The myth of unlimited storage.
For layout choices that change how large a tile is on the page, read The layout trap: aspect ratios and CSS grids. For how heavy a library can get on disk, use the Photography Cloud Storage & Cost Estimator.
Sharp where it matters, light where it multiplies
Upload masters you trust. Grids stay on thumbs; open views get Cloudflare-smart candidates, so the page stays fast without looking soft.
Also in Guides: The layout trap: aspect ratios and CSS grids · Video-first portfolio presentation · The myth of unlimited storage