<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Optimization on Kliku Kliku</title><link>https://klikukliku.dev/tags/optimization/</link><description>Recent content in Optimization on Kliku Kliku</description><generator>Hugo</generator><language>en</language><lastBuildDate>Tue, 03 Feb 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://klikukliku.dev/tags/optimization/index.xml" rel="self" type="application/rss+xml"/><item><title>Hugo Optimization: Complete Guide</title><link>https://klikukliku.dev/posts/hugo-performance-summary/</link><pubDate>Tue, 03 Feb 2026 00:00:00 +0000</pubDate><guid>https://klikukliku.dev/posts/hugo-performance-summary/</guid><description>&lt;h2 id="introduction"&gt;Introduction&lt;/h2&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;</description></item><item><title>Hugo JS Optimization: Bundling, Fingerprinting, and Caching in 15 Minutes</title><link>https://klikukliku.dev/posts/hugo-js-optimization/</link><pubDate>Tue, 27 Jan 2026 00:00:00 +0000</pubDate><guid>https://klikukliku.dev/posts/hugo-js-optimization/</guid><description>&lt;h2 id="introduction"&gt;Introduction&lt;/h2&gt;
&lt;p&gt;After &lt;strong&gt;&lt;a href="https://klikukliku.dev/posts/hugo-css-optimization"&gt;cleaning up CSS styles&lt;/a&gt;&lt;/strong&gt; and &lt;strong&gt;&lt;a href="https://klikukliku.dev/posts/hugo-image-optimization"&gt;optimizing images&lt;/a&gt;&lt;/strong&gt;, I focused on the JavaScript layer. At first glance, the situation looked innocent. The site was loading two files: a script from the theme and my own code for handling the color theme toggle. Together, they weighed less than three kilobytes. With such a small size, optimizing here might seem like overkill.&lt;/p&gt;
&lt;p&gt;However, the real challenge was hidden in the HTTP headers. I noticed that both files had a one-year cache lifetime. Unfortunately, their names lacked a unique identifier, or a &amp;ldquo;fingerprint.&amp;rdquo; This created a serious risk. It meant that after deploying any fixes, users would still use the old version of the code saved in their browsers.&lt;/p&gt;</description></item><item><title>CSS Optimization in Hugo: Minification and Bundling for Maximum Performance</title><link>https://klikukliku.dev/posts/hugo-css-optimization/</link><pubDate>Tue, 13 Jan 2026 00:00:00 +0000</pubDate><guid>https://klikukliku.dev/posts/hugo-css-optimization/</guid><description>&lt;h2 id="introduction"&gt;Introduction&lt;/h2&gt;
&lt;p&gt;We often focus on optimizing JavaScript or images, while treating CSS styles as somewhat secondary. We assume that since individual files weigh just a few kilobytes, they&amp;rsquo;re not a problem. But that&amp;rsquo;s a false assumption. The way we deliver these files to the browser can have a crucial impact on how quickly users see the finished page.&lt;/p&gt;
&lt;p&gt;When I looked into Chrome&amp;rsquo;s developer tools, I noticed a specific problem on my site. My page was loading fifteen separate CSS files. Combined, this generated a delay of around one point six seconds. Interestingly, the data size wasn&amp;rsquo;t the issue at all. GZIP compression was working correctly and reducing file weight by over sixty percent. The real bottleneck turned out to be the sheer number of HTTP requests. The browser was wasting time establishing connections instead of downloading content.&lt;/p&gt;</description></item><item><title>Hugo Image Processing: How I Reduced Page Size by 98%</title><link>https://klikukliku.dev/posts/hugo-image-optimization/</link><pubDate>Tue, 06 Jan 2026 00:00:00 +0000</pubDate><guid>https://klikukliku.dev/posts/hugo-image-optimization/</guid><description>&lt;h2 id="introduction"&gt;Introduction&lt;/h2&gt;
&lt;p&gt;Images are usually the biggest obstacle to website performance. Although Hugo generates fast static sites by nature, unoptimized images can completely cancel out this advantage. I decided to investigate this using my own website as a case study.&lt;/p&gt;
&lt;p&gt;Analysis in Chrome DevTools clearly showed the source of the problem. Images made up 96% of the total transfer, adding up to nearly 15 MB. I identified three large PNG files that caused most of this traffic and increased the load time to over 4 seconds. For mobile users, this meant a long wait and wasted data.&lt;/p&gt;</description></item></channel></rss>