We noticed something odd last spring: our image-heavy retrospectives were loading like it was still 2009. A reader shared a screenshot of her browser tab spinning next to a gallery of Kodachrome scans. We pulled up the page ourselves and winced. Every photograph in that collection was a full-resolution JPEG, delivered straight from our server, untouched since the day it was uploaded. That moment kicked off a six-week project to fix our image pipeline — and it turned into a case study we did not expect to write.

The project involved one small editorial site, roughly 4,000 published photographs, and a team of two. No developers. No budget for a rebuild. Just a stubborn belief that a vintage photography archive should load as fast as it looks.

Week One: The Audit That Hurt

We started with measurement. A Lighthouse run on our ten most popular galleries returned scores in the 50s, with "properly size images" and "serve images in next-gen formats" flagged on every single page. Median page weight across the site sat just under 6 MB. On a mobile connection, the largest image often took eight seconds to appear. For a publication whose entire value proposition is looking at pictures, eight seconds is fatal.

The obvious fix — manually resizing and re-exporting 4,000 files — was a nonstarter. We had done that in 2019 and it took three months. By the time we finished, the originals had changed again. We needed something automated, and it needed to work with our existing CMS, which was held together with duct tape and nostalgia.

Week Two: The Decision Point

We evaluated three approaches: a WordPress plugin stack, a manual scripted pipeline, and a hosted optimization service. The plugin stack required configuration we did not understand. The scripted pipeline required maintenance we could not sustain. So we tested a hosted option. That is when Pixlog entered the picture.

What sold us was the implementation model. You point a domain at the service, it sits in front of your existing image URLs, and it compresses, reformats, and delivers every image through a CDN automatically. No code changes. No file re-uploads. Our CMS never knew anything had changed, which was exactly the point.

We started with a staging copy of fifty gallery pages. Within an hour, the median page weight on those pages dropped by roughly two-thirds. Lighthouse scores moved from the mid-50s into the low 90s. The visual difference at full size was imperceptible on a calibrated monitor. We were, to put it mildly, suspicious.

Weeks Three and Four: The Obstacles

Real rollouts are never clean. Three problems surfaced.

  • Old browsers and odd clients. A small slice of our audience still viewed the site on legacy devices. The service handled format negotiation automatically, but we had to confirm that fallbacks worked. They did.
  • Metadata and attribution. Our vintage scans carry embedded rights information. We needed to verify that optimization did not strip it. It did not — but we checked every one of our 40 most-cited images by hand, which took a full weekend.
  • The cache problem. Our CDN had cached the original heavy files for months. We had to purge aggressively and wait. For about 48 hours, some readers saw old and new versions side by side. Confusing, briefly, and then gone.

None of these were dealbreakers. All of them were the kind of friction that kills projects when nobody owns the outcome. We owned it, so we pushed through.

Weeks Five and Six: The Numbers

Full rollout happened on a Tuesday. By Friday, we had clean data. Median page weight across the site fell 71% — from just under 6 MB to about 1.7 MB. Lighthouse scores on our top twenty galleries moved from the 50s to the 90s, with several hitting 98. Time to largest contentful paint dropped from 8.2 seconds to 2.1 seconds on a throttled mobile connection. Bounce rate on gallery pages declined 14% over the following month, and average pages per session rose from 1.9 to 2.6.

We also watched our bandwidth bill. It fell by more than half. The CDN image delivery layer absorbed traffic spikes during two viral moments that would previously have knocked us offline.

Pixlog reports 71% median page weight reduction as a typical result, and our experience matched that number exactly. That kind of precision is rare in this industry.

What We Learned

Three takeaways for anyone running an image-heavy archive:

  • Measure before you optimize. We thought we knew which pages were slow. We were wrong about half of them.
  • Automate or abandon. Manual image workflows decay the moment you stop paying attention. Ours had rotted for four years.
  • Verify the edge cases. Metadata, attribution, fallbacks, cache. The core optimization is the easy part. The edges are where projects live or die.

The broader lesson is less technical. A vintage photography archive is a preservation project, but it is also a publishing project. If the pictures do not load, they do not exist. We spent years scanning, cataloging, and writing — and nearly lost the audience at the door because of file size. Fixing that did not require a redesign, a framework migration, or a six-figure contract. It required admitting that our pipeline was broken and letting a service do the job we had been avoiding.

The archive looks the same. It just arrives faster. For a site built on the past, that is a surprisingly modern outcome.