How Gadget Pilipinas Reclaimed ~49 GB and Made Its Images Future-Ready

The problem we started with

Gadget Pilipinas has published tech content since 2008 — nearly two decades of photos, and every one of them was stored the old way: as heavyweight JPG/JPEG originals plus multiple resized copies for every page layout. By September 2026 the media library had grown to ~84,000 images, and server storage was climbing toward an uncomfortable level.

Three separate issues were compounding:

Storage bloat — every photo existed many times over (full-size original + ~9 resized thumbnails per image), and originals were never removed.
Slow pages — every article asked visitors to download JPGs that were far larger than needed for screen display.
Hidden garbage — years of platform migrations left orphaned files, broken database entries, and dead tracking tables that served no one.

The goal became simple: modernize how images are stored and served, reclaim the wasted space, and do it without breaking a single article.

What we did — the process, step by step

Phase 1 — Audit (understand the mess before touching it)

Before changing anything, we inventoried the entire media library from the database:

Counted every image attachment and its resized derivatives (~84,000 images × ~10 files each)
Identified ~2,000 “ghost” entries — records pointing at files that no longer existed on disk (artifacts of the old Facebook-era import pipeline)
Found 1,964 completely unreferenced images (~1.2 GB) — files no article, page, or widget used
Found two abandoned analytics tables holding ~13.4 million rows (~2.9 GB) of data no product used

Everything was catalogued before anything was deleted. Nothing was removed on a guess.

Phase 2 — Convert (JPG → WebP, in place, carefully)

The core move: convert every JPEG into WebP — the modern image format that delivers the same visual quality at a fraction of the size.

The conversion ran as a background worker in nightly low-traffic windows (12 AM–6 AM Philippine time), processing images in short, safe bursts so the live site never slowed. Key safeguards built in:

Original files were never touched during conversion — WebP copies were created alongside originals first
Ghost entries were detected and permanently excluded so they stopped failing every pass
Each conversion pass was time-capped and memory-guarded to protect the server
One stubborn edge case (a handful of files using the rare .jpe extension) was found and fixed with a one-line pattern correction — the kind of 1% problem that silently blocks 100% of completion

Result: 84,047 images converted. Zero broken during the process.

Phase 3 — Rewire every article (the “pair drain”)

Converting files isn’t enough — every article’s saved HTML still pointed at the old .jpg addresses. Each conversion produced a rewrite pair:

old image address → new WebP address

~357,000 of those pairs had to be applied across the site’s article text. The original drain design would have taken 18 nightly runs (~3 weeks). We optimized the worker to process more per pass and rewrote the driver to run until finished — completing all 357,000 rewrites in a single night (~1.5 hours).

Think of it like relabeling every recipe in a cookbook so each one points at the new jar instead of the old one — before throwing the old jars away.

Phase 4 — Validate (prove nothing broke)

Before deleting a single original, we ran an automated sweep across 40 articles spanning every era of the site (2008 → 2026), checking every image reference:

619 WebP references — all served correctly (100% pass)
Zero images broken by the conversion
The only flags were 14 pre-existing gaps from 2012–2016 articles (thumbnail files missing since before this project) and one filename with a special character that confuses automated checkers but works fine in browsers

Phase 5 — Purge (reclaim the space, with guards)

Only after validation passed did we delete the old JPG originals — and even then with a hard safety rule: a file was only deleted if its WebP twin existed and was healthy. 126 files without twins were automatically spared. Then the staged unreferenced-media trash was removed too, and both content-cache layers were purged so visitors instantly saw the new files.

The results

Storage reclaimed — the headline number

The uploads area dropped from ~69 GB to ~23.4 GB after removing 44.5 GB of JPG originals and 1.4 GB of unreferenced trash.

44.5 GB of JPG originals and thumbnails (845,000+ files) — now served as WebP
1.4 GB of unreferenced media trash
2.9 GB of abandoned database tracking tables

≈ 49 GB reclaimed in total — the uploads area alone shrank by roughly two-thirds (~69 GB → ~23.4 GB), plus ~2.9 GB of dead database tables.

What the purge actually removed

845,055 JPG files deleted (11.8 GB full-size originals + 32.7 GB resized thumbnails), plus 21,004 unreferenced trash files (1.4 GB). The 126 files with no WebP twin were spared by design.

Pipeline volumes at a glance

84,047 images converted, ~2,000 ghost entries excluded, 356,574 rewrites applied — zero broken at the end.

The efficiency story

The one change with the biggest time payoff: the content-rewrite drain. What was projected to take 18 nights finished in one after we widened the per-pass cap and let the worker run to completion instead of stopping early.

Drain optimization: 18 nights → 1 night.

How our AI harness helped

This was not a purely manual operation — and that is exactly why it could be done at this scale, in this timeframe, without disrupting a live news site. An AI operations harness handled the heavy, repetitive, and precise work across every phase:

Auditing at scale. The AI agent inventoried the full media library from the database — 84,047 attachments, every resized derivative, every broken reference — and produced the exact numbers that drove every decision. What would have taken a person days of SQL and spreadsheet work took automated passes measured in minutes.
Running and watching the overnight conversion. The conversion worker executed on schedule in the 12 AM–6 AM window, and the AI monitored each run: it detected when a pass stalled at the same two files for hours, traced the root cause to the rare .jpe extension, and flagged it for a one-line fix rather than letting the job fail silently forever.
Executing the rewrite drain. The AI drove the ~357,000 content rewrites to completion in a single night, applying the optimization (raising the per-pass cap) that compressed a 3-week projection into 1.5 hours.
Validating before any deletion. After conversion, the AI ran automated checks across 40 articles from every era of the site and confirmed 100% of WebP references served correctly — the evidence that made the purge safe to approve.
Performing the purge with guardrails. The deletion itself was executed by the harness under a hard rule (only delete a file whose WebP twin exists and is healthy), with every irreversible step gated on human approval. It then purged the caches so readers saw the new files immediately.
Documenting everything. The numbers, charts, and this very write-up were compiled by the AI from production logs — measured, not estimated.

The key principle: the AI did the work; a human owned every decision. Nothing destructive happened without review and approval, and every claim in this article traces back to a production log or a verification pass.

What this means for us as a business

Beyond the technical win, this project pays for itself in ways that show up on the balance sheet:

Lower server and storage costs

Storage is billed by the gigabyte, and backups multiply the bill. Reclaiming ~49 GB means:

Immediate headroom — the site now sits at roughly a third of its former uploads footprint, deferring any storage-plan upgrade.
Cheaper, faster backups — every backup now carries ~49 GB less data, which cuts both the storage cost and the time to restore if we ever need to.
Less bandwidth spend — WebP files are a fraction of the JPG weight, so every page view moves fewer bytes from server to reader. On a site with Gadget Pilipinas’ readership, that saving is continuous and compounding.

A faster site is a better business asset

Image weight is the biggest lever on page speed, and page speed drives outcomes we care about:

Better search ranking — Core Web Vitals are a known ranking signal; faster pages rank better and keep their positions.
Lower bounce rates — readers on slow or mobile connections stay when pages load fast, and every page view saves bandwidth on our side too.
More ad impressions served — a page that renders sooner keeps users engaged longer.

Future-ready

This project wasn’t just about cleaning up the past — it set the standard for everything that comes next:

WebP is now the house format. Every image that enters the site is converted to WebP before upload, so the bloat pattern can never rebuild itself. The old “upload the JPG, keep the source forever” habit is retired.
The pipeline is reusable. Audit → convert → rewire → validate → purge is a proven, guarded playbook. When the next format shift comes (AVIF, JPEG XL, or whatever follows), we run the same pipeline instead of inventing a new one.
AI-assisted operations are now part of how we run the site. We proved the model works: an AI harness doing the heavy lifting, a human making the calls. Future migrations, cleanups, and optimizations can be executed with the same speed and safety.

Illustrative projection: ~1.3 GB/month of growth under the old JPG workflow vs. ~0.35 GB/month now that WebP is the standard. The gap widens every month we don’t have to store and serve JPGs.

What would have happened if we hadn’t done this

The counterfactual is easy to sketch, because the site was on that trajectory:

Storage kept climbing. Every new article added JPG originals + ~9 thumbnails, month after month, with no removal mechanism. Hosting and backup costs grow with it.
Pages kept getting slower. Every article carried oversized images to every reader, on every visit — slower loads, higher mobile data use, worse Core Web Vitals scores, and the ranking and revenue consequences that follow.
The garbage stayed. Ghost entries would have failed background jobs forever; orphaned files and dead tables would have kept occupying space and complicating every future maintenance task.
The hard part got harder. Converting 84,000 images is far easier than converting 120,000. Every month of delay added ~1,000+ more images to the backlog.

Benefits that compound

Benefit	What changed
Storage	~49 GB reclaimed; media library now stores one efficient format instead of duplicates
Speed	Every article now serves smaller image files — faster loads, less bandwidth, better page-speed scores
Cost	Lower storage and backup footprint, less bandwidth per page view, storage upgrade deferred
Maintenance	Ghost entries excluded permanently; background jobs run clean; no more silent failures
Data hygiene	Orphaned files and dead analytics tables gone; catalog matches reality
Process	A reusable, guarded pipeline (audit → convert → rewire → validate → purge) for any future format change
Risk control	Nothing deleted without validation; deletion only when a verified replacement existed

The standing rule going forward

Every image that enters the site now follows the new standard: convert to WebP before upload, keep only the WebP. Combined with AI-assisted operations and a proven migration playbook, Gadget Pilipinas is leaner, faster, and ready for whatever format or growth comes next.

Giancarlo Viterbo

Founder, Chief Editor, and Sales Lead at Gadget Pilipinas | Website

Giancarlo Viterbo is a Filipino Technology Journalist, blogger and Editor of gadgetpilipinas.net, He is also a Geek, Dad and a Husband. He knows a lot about washing the dishes, doing some errands and following instructions from his boss on his day job. Follow him on twitter: @gianviterbo and @gadgetpilipinas.