Coder Legion - Recent posts tagged fotio

How We Made a Photo-Heavy Site Load Fast: Image Optimization and Edge Caching That Actually Moved

Tue, 14 Jul 2026 11:59:43 +0000

If your site's main content is images, performance is not a nice-to-have — it's the product. On a photography portfolio, every gallery is a wall of large files, and each one competes for bandwidth, blocks rendering, and drags down your Core Web Vitals.

We ran into exactly this while building fotio.app, a marketplace for booking professional photographers across 20+ cities in Spain. Portfolio pages routinely load dozens of high-resolution photos, and early on our Largest Contentful Paint (LCP) was embarrassing. This post walks through what we changed, what actually helped, and — importantly — the CDN and caching details that most "just add a CDN" articles skip.

The starting point

A typical portfolio page looked like this:

30–60 images per page, many well over 1 MB each
Original JPEGs served at full resolution regardless of the viewport
A single origin server, so a user in Mexico City pulled every byte across the Atlantic
No lazy loading — everything fetched on page load, including images far below the fold

The result was a heavy page, a slow first paint, and layout that jumped around as images popped in. Let's fix it in layers.

Layer 1: Serve modern formats

The single biggest win was switching away from unoptimized JPEG. AVIF and WebP produce dramatically smaller files at equivalent visual quality — AVIF frequently lands 40–50% smaller than a comparable JPEG.

The trick is to serve the best format the browser supports without forking your markup. The <picture> element handles this declaratively:

<picture>
  <source srcset="/img/session.avif" type="image/avif" />
  <source srcset="/img/session.webp" type="image/webp" />
  <img src="/img/session.jpg" alt="Outdoor family session in Seville" />
</picture>

The browser walks the sources top to bottom and uses the first format it understands, falling back to the plain JPEG for anything ancient.

Layer 2: Stop shipping desktop images to phones

A 2400px-wide photo on a 390px phone screen is pure waste. Responsive srcset lets the browser pick an appropriately sized file:

<img
  src="/img/session-800.jpg"
  srcset="/img/session-400.jpg 400w,
          /img/session-800.jpg 800w,
          /img/session-1600.jpg 1600w"
  sizes="(max-width: 600px) 90vw, 800px"
  alt="Couple love story session in Barcelona"
  loading="lazy"
  decoding="async"
/>

Two cheap wins hide in there: loading="lazy" defers off-screen images until the user scrolls near them, and decoding="async" keeps image decoding off the main thread.

Layer 3: Reserve space so the layout doesn't jump

Lazy-loaded images that pop in without reserved space cause Cumulative Layout Shift (CLS) — content jumping around as photos arrive. Always give the browser the dimensions up front:

<img src="/img/session.jpg" width="1600" height="1067" alt="..." />

For a nicer perceived load, we also render a tiny blurred placeholder (an LQIP — low-quality image placeholder) that's swapped for the real image once it arrives. It's a few hundred bytes of inlined base64 that makes the page feel instant even before the full photo lands.

Layer 4: CDN and edge caching — the part people gloss over

Everything above shrinks the files. A CDN changes where they come from, and this is where a photo-heavy site lives or dies.

Why it matters

With a single origin, distance becomes latency. A user far from your server pays a round-trip penalty on every request, and images are your heaviest resource. A CDN copies your files to edge servers physically close to the user, so the bytes travel a short distance instead of across the world.

How the cache actually behaves

The first request for a file from a given region is a cache miss: the CDN fetches it from your origin, stores a copy on the nearest edge node, and serves it. Every subsequent request from that region is a cache hit — served straight from the edge, never touching your origin. Your job is to maximize hits and make each cached copy live as long as possible.

Cache-Control headers

For images that never change, tell browsers and the CDN to hold onto them essentially forever:

Cache-Control: public, max-age=31536000, immutable

That's one year, and immutable tells the browser not to even bother revalidating. HTML is the opposite — it changes, so it gets a short TTL or no caching at all. Applying one blanket rule to everything is a classic mistake; split your static assets from your dynamic documents.

Cache busting with hashed filenames

Once a file is cached "forever," how do you ever update it? You don't change the content at the same URL — you change the URL. Embed a content hash in the filename:

session.a3f9b2.avif   →   session.7c1e04.avif   (after re-export)

The old URL stays cached and harmless; the new one is a fresh miss that gets cached in turn. immutable plus hashed filenames is the standard pairing, and it means you never fight a stale cache again.

Transform at the edge

Many CDNs (Cloudflare Images, Fastly, bunny.net, imgix) can convert and resize on the fly at the edge, reading the browser's Accept header and returning AVIF or WebP from a single canonical URL:

/cdn/session.jpg?format=auto&width=800

This collapses the <picture>/srcset gymnastics into one source of truth and offloads the work from your origin entirely.

The metric this moves

Edge caching lands squarely on TTFB (time to first byte). A cache hit from a nearby edge answers in tens of milliseconds; a trip to a distant origin can be several hundred. Since your LCP element on a portfolio page is almost always an image, a faster TTFB on that image flows straight through to a faster LCP.

What the numbers looked like

Rough before/after on a representative gallery page (measured with WebPageTest from a mid-tier connection):

Metric	Before	After
Page weight	~9 MB	~1.8 MB
LCP	~4.8 s	~1.6 s
TTFB (image, distant region)	~380 ms	~40 ms
CLS	0.21	0.02

Most of the weight reduction came from format + responsive sizing; most of the latency reduction came from edge caching. They're complementary — you want both.

Takeaways

If you're optimizing a photo-heavy site, work in this order:

Modern formats (AVIF/WebP with a JPEG fallback) — biggest byte savings.
Responsive srcset + lazy loading — stop over-serving and over-fetching.
Explicit dimensions + LQIP — kill layout shift and improve perceived speed.
CDN with aggressive, correct caching — long immutable TTLs, hashed filenames, edge transforms.

None of these are exotic, but the caching layer is the one most teams under-configure, and it's the one that decides whether a user two continents away has a good time.

You can see the end result on a genuinely image-dense site at fotio.app — every city and portfolio page leans on exactly this pipeline.

Your Photos Are Telling Strangers Where You Live: A Developer's Guide to EXIF and Privacy

Tue, 23 Jun 2026 07:13:01 +0000

Every JPEG your phone or camera produces ships with a hidden passenger: EXIF metadata. Most people never look at it. Most developers never strip it. And that gap has leaked everything from celebrities' home addresses to the exact location of an active-duty soldier's base.

If you build anything that touches user-uploaded images — a marketplace, a social app, a photo gallery — this is one of those quiet responsibilities that's easy to ignore until it's a headline. Here's what's actually in that metadata, how to read it, and how to strip it in a few lines of code.

What's hiding in a photo

EXIF (Exchangeable Image File Format) is a block of key–value data embedded in the file itself. A typical photo carries:

GPS coordinates — latitude, longitude, sometimes altitude. Precise enough to drop a pin on your front door.
Timestamps — when the shot was taken, down to the second.
Camera & lens — make, model, and often the camera body's serial number.
Settings — ISO, aperture, shutter speed, focal length.
Software — what edited the file and when.

Individually, harmless. Together, they're a movement log. Geotagged photos posted over time draw a map of where you live, work, sleep, and travel — and the timestamps tell anyone when you're not home.

Reading EXIF (so you can see the problem)

Python (Pillow)

from PIL import Image
from PIL.ExifTags import TAGS, GPSTAGS

img = Image.open("photo.jpg")
exif = img.getexif()

for tag_id, value in exif.items():
    tag = TAGS.get(tag_id, tag_id)
    print(f"{tag:25}: {value}")

# GPS lives in its own sub-block (IFD)
gps_ifd = exif.get_ifd(0x8825)  # GPSInfo
for key, val in gps_ifd.items():
    print(f"{GPSTAGS.get(key, key):25}: {val}")

Turning the raw GPS tuples into decimal degrees:

def to_decimal(dms, ref):
    degrees, minutes, seconds = [float(x) for x in dms]
    dec = degrees + minutes / 60 + seconds / 3600
    return -dec if ref in ("S", "W") else dec

lat = to_decimal(gps_ifd[2], gps_ifd[1])   # GPSLatitude, GPSLatitudeRef
lon = to_decimal(gps_ifd[4], gps_ifd[3])   # GPSLongitude, GPSLongitudeRef
print(f"https://maps.google.com/?q={lat},{lon}")

Run that on a geotagged photo and you'll get a clickable map link straight to wherever it was taken. That's the whole point — it's that easy for anyone else, too.

JavaScript (browser, with `exifr`)

import exifr from 'exifr';

// Read just the GPS — works on a File from an <input>
const gps = await exifr.gps(file);
console.log(gps?.latitude, gps?.longitude);

// Or pull everything
const data = await exifr.parse(file);
console.log(data.Make, data.Model, data.DateTimeOriginal);

Command line (ExifTool)

exiftool photo.jpg            # dump everything
exiftool -gps:all photo.jpg   # just the location data

Stripping EXIF (so you stop being the problem)

One-off, CLI

# ExifTool — removes all metadata
exiftool -all= photo.jpg

# ImageMagick — re-encode without metadata
convert photo.jpg -strip clean.jpg

Python

# piexif: surgical removal, keeps the pixels untouched
import piexif
piexif.remove("photo.jpg", "clean.jpg")

# Pillow: re-save without the exif kwarg
from PIL import Image
img = Image.open("photo.jpg")
img.save("clean.jpg")  # no exif= passed → metadata dropped

Server-side on upload (Node, `sharp`)

This is the one that matters in production. Strip metadata as part of your upload pipeline, automatically, for every image. Don't trust users to do it.

import sharp from 'sharp';

await sharp(inputBuffer)
  .rotate()            // bake in EXIF orientation BEFORE you drop it
  .jpeg({ quality: 82 })
  .toFile('clean.jpg'); // sharp strips metadata by default

⚠️ Gotcha: EXIF has an Orientation tag that tells viewers to rotate the image. If you strip metadata without applying that rotation first, photos that looked fine suddenly appear sideways. Always auto-orient (sharp's .rotate() with no args) before discarding metadata.

Client-side, before it ever uploads

Drawing an image onto a <canvas> and re-exporting it discards EXIF as a side effect:

function stripExif(file) {
  return new Promise((resolve) => {
    const img = new Image();
    img.onload = () => {
      const canvas = document.createElement('canvas');
      canvas.width = img.naturalWidth;
      canvas.height = img.naturalHeight;
      canvas.getContext('2d').drawImage(img, 0, 0);
      canvas.toBlob(resolve, 'image/jpeg', 0.9);
    };
    img.src = URL.createObjectURL(file);
  });
}

(Same orientation caveat applies — handle rotation before you rely on this.)

"Doesn't the platform strip it for me?"

Sometimes. Most large social networks strip EXIF on upload — but the behavior is inconsistent and changes without notice. Direct file delivery (email attachments, cloud links, raw downloads, messaging apps that send "as file") frequently keeps everything intact. The safe assumption: if you didn't strip it, it's still there.

There's a real trade-off, too. Photographers and archivists often want metadata — copyright, camera settings, capture time. So the right rule isn't "always nuke it," it's be deliberate: strip location and serial numbers from anything public-facing, and keep the rest only where it's genuinely useful and the user consents.

Where this shows up in the real world

When you run an image-heavy product, metadata handling stops being a curiosity and becomes part of your duty of care. At Fotio, where the whole business is delivering professional photo galleries from shoots across Spain, this is exactly the kind of detail that separates a polished pipeline from a leaky one — high-resolution images that look great, without quietly broadcasting a client's GPS trail. If you're curious how an image-first product is put together end to end, you can poke around at fotio.app.

The one-line takeaway

Treat EXIF like any other untrusted, potentially sensitive payload: inspect it, strip what's risky, and never assume someone else already handled it.

Add a metadata-stripping step to your upload pipeline today. It's a handful of lines, and it closes a privacy hole most apps don't even know they have.

Do you strip EXIF in your projects — client-side, server-side, or not at all? And have you ever found something alarming in a photo's metadata? Share it in the comments.