Introduction#

Over the past few weeks, I conducted a comprehensive optimization of my Hugo-based website. What started as curiosity about whether I could squeeze more performance out of a static site generator turned into a series of experiments with concrete, measurable results.

The starting point was good. Hugo naturally generates fast pages. My Lighthouse score hovered around 92-94 points. However, analysis in Chrome DevTools revealed problems invisible to the naked eye. Nearly fifteen megabytes of transfer on the homepage. Fifteen separate CSS files generating one and a half seconds of delay. No caching strategy for returning visitors.

After implementing all optimizations, the situation looks completely different. Transfer dropped to about three hundred fifty kilobytes. Lighthouse shows stable 96-98 points. Returning visitors load the page almost instantly thanks to aggressive caching.

In this post, I’ll summarize the entire journey. We’ll go through each optimization area, from images through styles and scripts to server configuration. I’ll show which changes brought the biggest impact and why the order of implementation matters.

Anatomy of the Problem#

Before we dive into solutions, it’s worth understanding the scale of the challenge. Analysis of the HAR file from Chrome DevTools gave me the complete picture.

What the Diagnostics Revealed#

The page made thirty-four HTTP requests on first load. Total transfer exceeded fifteen megabytes. However, the distribution was uneven, and it was precisely in this unevenness that the optimization roadmap was hidden.

Images accounted for ninety-six percent of all transfer. Three PNG screenshots weighed nearly fifteen megabytes combined. They alone generated over four seconds of loading time.

CSS styles took up only twenty-nine kilobytes but were scattered across fifteen separate files. Each request meant about one hundred milliseconds of overhead. Combined, this resulted in one and a half seconds just for styles.

JavaScript from Google Analytics and Tag Manager added another seven hundred thirty-six kilobytes. That’s twenty-five times more than all the site’s CSS.

Impact Hierarchy#

This analysis immediately indicated priorities. There’s no point optimizing CSS if images consume ninety-six percent of transfer. The order of actions had to reflect the real impact on performance.

That’s why I started with images, then moved to CSS bundling, followed by JavaScript, and finally tackled HTTP server configuration. This sequence isn’t accidental. Each subsequent step builds on the previous one and gives increasing control over the whole.

Images: The Biggest Game Changer#

Image optimization is undoubtedly the most important single change you can make in a Hugo project. In my case, it brought a ninety-seven percent reduction in transfer.

The Problem in Numbers#

Three PNG screenshots weighed nearly fifteen megabytes combined. The PNG format, while excellent for simple graphics, is highly inefficient for photos and screenshots with gradients. Additionally, images were served at full 4K resolution, even though the container on the page never exceeded twelve hundred pixels in width.

The Solution#

I used Hugo’s built-in image processing mechanism. I created a shortcode that automatically converts images to WebP format, generates responsive versions for different screen sizes, and adds lazy loading.

Key elements of the solution include conversion to WebP at eighty percent quality, generating 800px, 1200px, and 1600px variants, and the loading=“lazy” attribute for images below the fold.

The Result#

Image transfer dropped from fifteen megabytes to about three hundred fifty kilobytes. Loading time decreased from over four seconds to a fraction of a second. Most importantly, visual quality remained virtually unchanged.

The detailed implementation, including full shortcode and cover partial code, is described in the dedicated post: Hugo Image Processing: How I Reduced Page Size by 98%.

CSS: From Fifteen Files to One#

After dealing with images, the next step was organizing the style layer. The problem wasn’t in file size but in their fragmentation.

The Problem in Numbers#

Fifteen separate CSS files generated a combined one and a half seconds of delay. Even though the total size was only twenty-nine kilobytes after GZIP compression, each HTTP request carried a time overhead of about one hundred milliseconds.

The Solution#

Hugo Pipes allows bundling multiple CSS files into one. I used resources.Match to gather all styles from the theme, resources.Concat to combine them into a single file, minify for compression, and fingerprint to add a unique hash to the filename.

Additionally, I implemented a preload hint that informs the browser about the loading priority of the main stylesheet.

The Result#

The number of style requests dropped from fifteen to three. CSS loading time decreased from one and a half seconds to one hundred thirty-five milliseconds. That’s a ninety-two percent reduction.

The full implementation along with troubleshooting common issues can be found in: CSS Optimization in Hugo: Minification and Bundling.

JavaScript: Fingerprinting and Cache Security#

The JavaScript layer was relatively light but had a critical architectural problem. Files had a year-long cache set but lacked fingerprinting. This meant that after deploying fixes, users could use old code for up to a year.

The Problem in Numbers#

Two JavaScript files with a combined weight of under three kilobytes weren’t a performance problem. The problem was the risk of serving outdated code from the browser cache.

The Solution#

I combined both files into a single bundle using Hugo Pipes. I added fingerprinting, which changes the filename with every code modification. I also implemented Subresource Integrity, the integrity attribute, which allows the browser to verify that the downloaded file hasn’t been tampered with.

The Result#

The number of requests dropped by half. Transfer decreased by thirty-six percent. Most importantly, the cache became safe. Any change in code automatically invalidates the old version in users’ browsers.

Implementation details are described in: JS Optimization in Hugo: Bundling and Fingerprinting.

HTTP Server: GZIP and Cache Headers#

The final piece of the puzzle was configuring the server itself. Even the best-optimized files can be slow to deliver without proper HTTP headers.

Two Pillars of Server Optimization#

The first pillar is GZIP compression. The algorithm reduces text file sizes by sixty to seventy percent without any quality loss. In my case, the CSS file shrunk from twenty-five to five kilobytes.

The second pillar is cache headers. For fingerprinted files like bundled CSS or JavaScript, I set cache to one year with the immutable directive. For HTML, cache is one hour with forced revalidation. This strategy means returning visitors load static resources in zero milliseconds, directly from disk.

The Result#

The first visit benefits from GZIP and loads the page much faster. Every subsequent visit is practically instant because the browser doesn’t connect to the server at all for styles and scripts.

Full .htaccess configuration for Apache and verification instructions can be found in: HTTP Server Optimization for Hugo: GZIP and Cache Headers.

Minification Configuration#

Beyond bundling and caching, it’s also worth fine-tuning the minification process in Hugo. Default settings are conservative. A more aggressive configuration allows squeezing an additional dozen percent from file sizes.

In the hugo.toml file, you can set removal of comments and unnecessary whitespace from HTML, rounding numeric values in CSS to two decimal places, and shortening variable names in JavaScript.

These changes combined with –minify and –gc flags during build give optimal results without risking code breakage.

Results Summary#

After implementing all optimizations, I can compare the initial state with the final one.

Data Transfer#

Images: from fifteen megabytes to three hundred fifty kilobytes. A ninety-seven percent reduction.

CSS: similar size, but loading time from one and a half seconds to one hundred thirty-five milliseconds. A ninety-two percent reduction.

JavaScript: from two files to one, transfer reduced by thirty-six percent, plus secure cache.

HTTP Requests#

Before: thirty-four requests. After: about fourteen requests. A sixty percent reduction.

Lighthouse Performance#

Mobile: from 94 to 97 points. Desktop: stable 90-92 points. Total Blocking Time on mobile dropped by forty-nine percent.

User Experience#

First visit: page loads in a fraction of a second instead of several seconds. Subsequent visits: static resources loaded from cache in zero milliseconds.

Conclusions and Recommendations#

After going through the entire optimization path, I have several observations that may be useful to others.

Order Matters#

Start with images. That’s almost always the biggest problem. Only then tackle CSS and JS bundling. Finally, configure the server. This sequence maximizes impact with minimal effort.

Measure, Don’t Guess#

Chrome DevTools and HAR files are your friends. Without hard data, it’s easy to waste time on optimizations that have no real impact. Lighthouse shows the overall score, but it’s network analysis that reveals the true bottlenecks.

Fingerprinting is Mandatory#

If you want to aggressively cache resources, you must have fingerprinting. Without it, you risk serving outdated code to users. Hugo handles this natively through the fingerprint function in Hugo Pipes.

Simple Solutions Work#

None of the described optimizations required external tools or complex infrastructure. Everything relies on Hugo’s built-in mechanisms and standard server configuration. This makes solutions easy to maintain and replicate in other projects.

Your Turn#

Optimization is not a one-time fix. It is a continuous process. My score of 98 out of 100 in Lighthouse looks great today, but technology moves fast. Web Vitals standards might change in six months. Chrome might introduce new compression tools.

So, I do not want to just leave you with a list of links. I suggest you start with a simple audit. Open DevTools on your website right now. Go to the Network tab and refresh the page with the cache cleared. Check how big your images are. Also, check if you are loading a heavy library like jQuery just for one simple slider.

Good luck fighting for every kilobyte.

Sources#