Minify HTML

Why I Started Obsessing Over HTML File Size (And What Actually Fixed It)

Last year I was building a photography portfolio site — one of those dark-background, full-bleed image showcase pages that every photographer eventually builds. The images were optimized, WebP format, lazy-loaded. I was proud of it. Then I ran a Lighthouse audit and got slapped with a "reduce unused code" warning pointing squarely at my HTML files themselves. The HTML. I hadn't even considered that.

I'd spent three hours shaving 40KB off a hero image, and here was my HTML sitting at 28KB because I'd left in every comment I'd written to remind myself what each section did, plus all the indentation from my code editor's auto-format feature. Turns out those two things alone were responsible for almost a quarter of my page weight. That's when I started actually using Minify HTML as a regular part of my workflow.

What the Tool Actually Does to Your Markup

Minify HTML strips out everything a browser doesn't need to render your page: whitespace between tags, inline comments, redundant attribute quotes, unnecessary closing tags in certain contexts, and blank lines. What you're left with is a single dense string of markup that looks unreadable to humans but is functionally identical to what you started with.

Here's a concrete example. Take a typical image gallery card structure:

<!-- Gallery item -->
<div class="gallery-card">
    <figure>
        <img 
            src="photo-001.webp" 
            alt="Mountain at dusk" 
            loading="lazy"
        >
        <figcaption>
            Taken at 5:47 AM, Uttarakhand
        </figcaption>
    </figure>
</div>

After running through Minify HTML, that becomes something like:

<div class="gallery-card"><figure><img src="photo-001.webp" alt="Mountain at dusk" loading="lazy"><figcaption>Taken at 5:47 AM, Uttarakhand</figcaption></figure></div>

Same output in the browser. Smaller payload over the wire. If you have a page with sixty gallery cards, that whitespace and comment removal adds up to several kilobytes without touching a single image.

The Part That Matters for Image-Heavy Pages Specifically

Photography and image-showcase sites have a characteristic that makes HTML minification more impactful than on a typical blog: they repeat similar HTML structures dozens or hundreds of times. A masonry grid with 80 photos has 80 nearly-identical card elements. Every space character, every newline, every indent exists 80 times over.

I tested this with my own portfolio. My gallery page had 72 image cards. Raw HTML from my templating engine: 41KB. After running through Minify HTML: 17KB. That's a 59% reduction in document size, and I changed absolutely nothing about the images themselves. On a mobile connection — where a lot of photography traffic actually comes from, people showing someone a photo on their phone — that difference is genuinely felt as perceived load speed.

The other thing specific to image pages: inline SVG icons. If you're using SVG for your UI chrome (download buttons, share icons, zoom controls), those SVG blocks inside your HTML are verbose. Minify HTML handles inline SVG as well, collapsing the whitespace inside those elements too. A typical social share icon SVG can go from 340 bytes down to under 200.

How I Actually Use It in Practice

My workflow is simple. I build everything in my development environment with full formatting and comments intact — that's where I'm reading and editing the code constantly, so readability matters. When I'm ready to push to production:

1. Export or copy the final rendered HTML from my build process
2. Paste into Minify HTML
3. Click minify
4. Copy the output and use it in the production template

For static sites this is a one-time step per page. For CMS-driven sites, I use it to minify the core template files — the header, footer, and page shell — and let the dynamic content slots remain as-is. You get most of the benefit from the structural scaffolding, which is static anyway.

One thing I've learned: don't run it on HTML that contains inline JavaScript with specific whitespace dependencies. Rare, but if you have a <script> tag with template literals that preserve newlines intentionally, test the output before deploying. In practice this almost never comes up in image gallery contexts, but worth knowing.

Reading the Output Diff

What I appreciate about Minify HTML is that it shows you a before/after size comparison immediately. This matters because it tells you whether minification is actually worth it for your specific file. On a 4KB page, you might save 900 bytes — not nothing, but not transformative. On a 38KB page, you might save 18KB, which changes your Time to First Byte numbers in meaningful ways.

I've started using the size reduction percentage as a code smell indicator. If I paste in a page and get a 65%+ reduction, that tells me my source HTML has too much whitespace relative to content — usually a sign that my templating indentation is nested too deep. If I'm getting 15-20% reductions, my source is already reasonably lean. The tool becomes a feedback mechanism, not just a compression step.

Things Photographers Specifically Get Wrong About Page Weight

Most photographers obsess over image compression — which is correct, images are usually 80-95% of page weight. But there's a mental accounting error that happens: once the images are optimized, people assume the job is done and ignore everything else. The HTML, CSS, and JavaScript are "negligible" in comparison.

That's true in absolute terms for one page. But consider:

• Your HTML loads first, before images even begin fetching
• The browser parses HTML to build the DOM before it can start rendering anything
• On portfolio sites, the HTML structure itself is what the crawler indexes for SEO
• Every kilobyte of HTML is blocking, while images are non-blocking once the page structure is parsed

Shaving 20KB off your HTML has a disproportionate effect on Time to Interactive compared to shaving the same 20KB off an image that loads after the page is already visually rendered. This is why I keep coming back to Minify HTML even though it feels like a small optimization on paper.

The Honest Limitations

Minify HTML is a processing step, not a silver bullet. It does nothing for CSS or JavaScript — you'll want separate tools for those. It also doesn't help with server response time, CDN configuration, or caching headers, which often matter more than file size. And if your HTML is already being served with gzip compression enabled on your server (which it should be), the practical savings from minification get smaller because gzip is very good at compressing repetitive whitespace anyway.

But here's the thing: gzip doesn't eliminate the parsing overhead. The browser decompresses the file, then parses it. A smaller file means a smaller DOM to build, which means faster JavaScript execution on top of that DOM. The savings compound in ways that aren't visible from just looking at transfer size numbers.

Where This Fits in a Real Optimization Workflow

If I were advising someone building a photography or image portfolio site today, the optimization priority order would be: image format and compression first, lazy loading second, proper caching headers third, then HTML and CSS minification. Minify HTML sits at step four — not because it's unimportant, but because the earlier steps have bigger returns.

Once you've done the obvious stuff, though, HTML minification is one of the easiest wins remaining. Paste, click, copy. Ten seconds of work per page. On a site where you're already at 90% of theoretical best performance on images, it's one of the few levers left that requires zero tradeoffs — you lose nothing except comments that no visitor ever reads anyway.

I still keep my development files fully formatted and commented. That's where I think. But what actually goes to production is the minified version, and that habit alone has improved my average page weight by 12-18KB across the board. For something I do in ten seconds per file, that's a trade I'll take every time.