<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Css on Kliku Kliku</title><link>https://klikukliku.dev/tags/css/</link><description>Recent content in Css on Kliku Kliku</description><generator>Hugo</generator><language>en</language><lastBuildDate>Tue, 03 Mar 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://klikukliku.dev/tags/css/index.xml" rel="self" type="application/rss+xml"/><item><title>Styling Cusdis: Taking Control of the Iframe Without Touching the Source</title><link>https://klikukliku.dev/posts/cusdis-custom-styles/</link><pubDate>Tue, 03 Mar 2026 00:00:00 +0000</pubDate><guid>https://klikukliku.dev/posts/cusdis-custom-styles/</guid><description>&lt;h2 id="introduction"&gt;Introduction&lt;/h2&gt;
&lt;p&gt;I recently looked into implementing a comment system based on Cusdis. It&amp;rsquo;s a lightweight and privacy-friendly solution, but it comes with a UI challenge: the widget renders inside an &lt;code&gt;iframe&lt;/code&gt;.&lt;/p&gt;
&lt;p&gt;What does this mean for us? An iframe creates an isolated environment. The CSS styles we have in our project don&amp;rsquo;t leak inside. As a result, if our layout has specific branding, the default, minimalist Cusdis design looks like a part of something else.&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></channel></rss>