https://klikukliku.dev/pl/tags/performance/Recent content in Performance on Kliku KlikuHugoplTue, 10 Mar 2026 00:00:00 +0000https://klikukliku.dev/pl/posts/hugo-comments-cusdis/Tue, 10 Mar 2026 00:00:00 +0000https://klikukliku.dev/pl/posts/hugo-comments-cusdis/<h2 id="wstęp">Wstęp</h2> <p>Przeglądając systemy komentarzy do blogów statycznych, wziąłem na warsztat Cusdis — bo obiecuje podejście „minimum tarcia”: prosty widget, bez reklam i bez ciężkiej analityki w tle. Cusdis pozycjonuje się jako lekka, prywatnościowa alternatywa dla Disqus i jest rozwijany jako projekt open source, z opcją self-hostingu oraz wariantem zarządzanym na cusdis.com. Szczegółowy przewodnik po self-hostingu Cusdis znajdziesz w dedykowanym wpisie: <a href="https://klikukliku.dev/pl/posts/cusdis-self-hosted-vps">Self-Hosting Cusdis na VPS</a>.</p> <p>Moim celem było sprawdzić dwie rzeczy: jak wygląda sensowna integracja z Hugo (bez wklejania skryptów „na dziko”) oraz jaki realny narzut pojawia się na stronie, gdy komentarze są włączone.</p>https://klikukliku.dev/pl/posts/hugo-comments-giscus/Tue, 17 Feb 2026 00:00:00 +0000https://klikukliku.dev/pl/posts/hugo-comments-giscus/<h2 id="wstęp">Wstęp</h2> <p>W ramach przeglądu rozwiązań do obsługi komentarzy na blogach statycznych, wziąłem na warsztat <strong>Giscus</strong>. To narzędzie typu open-source, które wykorzystuje GitHub Discussions jako swój backend.</p> <p>Zaintrygowała mnie przede wszystkim obietnica wydajności i prywatności.Poniżej przedstawiam analizę tego rozwiązania, instrukcję implementacji w Hugo oraz wnioski z testów wydajnościowych.</p> <h2 id="czym-właściwie-jest-giscus">Czym właściwie jest Giscus?</h2> <p>Giscus to widget, który łączy Twoją stronę bezpośrednio z API GitHuba. Kiedy czytelnik zostawia komentarz pod wpisem, system automatycznie tworzy nową dyskusję (lub dopisuje odpowiedź) w powiązanym repozytorium na GitHubie.</p>https://klikukliku.dev/pl/posts/hugo-comments-disqus/Tue, 10 Feb 2026 00:00:00 +0000https://klikukliku.dev/pl/posts/hugo-comments-disqus/<h2 id="wstęp">Wstęp</h2> <p>Disqus to prawdopodobnie pierwsze rozwiązanie, które przychodzi nam do głowy, gdy myślimy o komentarzach na stronach statycznych. Jest z nami od 2007 roku, obsługuje miliony witryn i zdejmuje z nas ciężar tworzenia własnego backendu.</p> <p>Postanowiłem sprawdzić, jak wygląda jego integracja z Hugo w 2026 roku, ale przede wszystkim, jaki jest rzeczywisty koszt tej wygody. Przeprowadziłem testy wydajnościowe na tym blogu i wyniki mogą was zaskoczyć.</p> <h2 id="czym-właściwie-jest-disqus">Czym właściwie jest Disqus?</h2> <p>W skrócie: to „komentarze jako usługa”. My dostarczamy statyczny frontend, a Disqus bierze na siebie całą brudną robotę: hosting bazy danych, walkę ze spamem, moderację i logowanie użytkowników (Google, Facebook, Twitter).</p>https://klikukliku.dev/pl/posts/hugo-performance-summary/Tue, 03 Feb 2026 00:00:00 +0000https://klikukliku.dev/pl/posts/hugo-performance-summary/<h2 id="wstęp">Wstęp</h2> <p>Przez ostatnie tygodnie przeszedłem przez kompleksową optymalizację mojej strony. Zaczęło się od prostej ciekawości czy da się wycisnąć więcej z tego generatora stron statycznych — a skończyło na serii eksperymentów, które dały wymierne rezultaty.</p> <p>Punkt wyjścia był naprawdę przyzwoity. Hugo z definicji generuje szybkie strony. Mój wynik w Lighthouse oscylował gdzieś między 92 a 94 punktami. Ale kiedy zagłębiłem się w Chrome DevTools i zerknąłem na szczegóły transferu sieciowego, zobaczyłem rzeczy, których gołym okiem nie widać. Prawie 15 megabajtów transferu na stronę główną. 15 osobnych plików CSS, które generowały półtorej sekundy opóźnienia. Zero strategii cache&rsquo;owania dla osób, które wracają na stronę.</p>https://klikukliku.dev/pl/posts/hugo-js-optimization/Tue, 27 Jan 2026 00:00:00 +0000https://klikukliku.dev/pl/posts/hugo-js-optimization/<h2 id="wstęp">Wstęp</h2> <p>Po <strong><a href="https://klikukliku.dev/pl/posts/hugo-css-optimization">uporządkowaniu stylów CSS</a></strong> i <strong><a href="https://klikukliku.dev/pl/posts/hugo-image-optimization">optymalizacji obrazów</a></strong>, zająłem się warstwą JavaScript. Na pierwszy rzut oka sytuacja wyglądała niewinnie. Strona ładowała dwa pliki: skrypt z motywu oraz mój własny kod obsługujący przełączanie koloru motywu. Łącznie ważyły one niespełna trzy kilobajty. Przy tak małym rozmiarze mogłoby się wydawać, że optymalizacja w tym miejscu to sztuka dla sztuki.</p> <p>Prawdziwe wyzwanie kryło się jednak w nagłówkach HTTP. Zauważyłem, że oba pliki miały ustawiony roczny czas życia w pamięci podręcznej. Niestety, w ich nazwach brakowało unikalnego identyfikatora, czyli tak zwanego fingerprintu. To stwarzało poważne ryzyko. Oznaczało bowiem, że po wdrożeniu jakichkolwiek poprawek, użytkownicy nadal korzystaliby ze starej wersji kodu zapisanej w przeglądarce.</p>https://klikukliku.dev/pl/posts/hugo-server-optimization/Tue, 20 Jan 2026 00:00:00 +0000https://klikukliku.dev/pl/posts/hugo-server-optimization/<h2 id="wstęp">Wstęp</h2> <p>Często skupiamy się na minifikacji HTML czy bundlingu CSS, uznając to za koniec optymalizacji. Zauważyłem jednak, że nawet najlepiej przygotowane pliki potrafią ładować się wolno, jeśli zapomnimy o warstwie serwera HTTP. To właśnie tam leży niewykorzystany potencjał, który warto zagospodarować.</p> <p>W mojej praktyce kluczowe okazują się dwa elementy konfiguracji. Po pierwsze, kompresja GZIP. Z mojego doświadczenia wynika, że potrafi ona zredukować rozmiar plików tekstowych o sześćdziesiąt do siedemdziesięciu procent. Po drugie, odpowiednie nagłówki Cache. Dzięki nim eliminujemy zbędne zapytania przy kolejnych wizytach użytkownika. Pokażę wam dzisiaj, jak skonfigurować serwer dla strony opartej na Hugo, aby wycisnąć maksimum możliwości ze statycznych plików.</p>https://klikukliku.dev/pl/posts/hugo-css-optimization/Tue, 13 Jan 2026 00:00:00 +0000https://klikukliku.dev/pl/posts/hugo-css-optimization/<h2 id="wstęp">Wstęp</h2> <p>Często skupiamy się na optymalizacji JavaScriptu czy obrazów, a style CSS traktujemy nieco po macoszemu. Wydaje nam się, że skoro pojedyncze pliki ważą zaledwie kilka kilobajtów, to nie stanowią problemu. Jednak to mylne założenie. Sposób, w jaki dostarczamy te pliki do przeglądarki, może mieć kluczowy wpływ na to, jak szybko użytkownik zobaczy gotową stronę.</p> <p>Kiedy zajrzałem do narzędzi deweloperskich w Chrome, zauważyłem u siebie konkretny problem. Moja strona ładowała aż piętnaście osobnych plików CSS. Sumarycznie generowało to opóźnienie rzędu jednej i sześciu dziesiątych sekundy. Co ciekawe, problemem wcale nie był rozmiar danych. Kompresja GZIP działała poprawnie i redukowała wagę plików o ponad sześćdziesiąt procent. Prawdziwym wąskim gardłem okazała się sama liczba zapytań HTTP. Przeglądarka traciła czas na nawiązywanie połączeń, zamiast na pobieranie treści.</p>https://klikukliku.dev/pl/posts/hugo-image-optimization/Tue, 06 Jan 2026 00:00:00 +0000https://klikukliku.dev/pl/posts/hugo-image-optimization/<h2 id="wstęp">Wstęp</h2> <p>Obrazy to zazwyczaj największa przeszkoda w osiągnięciu wysokiej wydajności stron internetowych. Choć Hugo generuje z natury szybkie witryny statyczne, nieoptymalizowane grafiki potrafią całkowicie zniweczyć tę przewagę. Postanowiłem przyjrzeć się temu bliżej na przykładzie własnej strony.</p> <p>Analiza w Chrome DevTools jasno wskazała źródło problemu. Obrazy stanowiły aż dziewięćdziesiąt sześć procent całego transferu, co dawało prawie piętnaście megabajtów danych. Namierzyłem trzy duże grafiki w formacie PNG, które generowały większość tego ruchu i wydłużały czas ładowania do ponad czterech sekund. Dla użytkowników mobilnych oznaczało to długie oczekiwanie i niepotrzebne zużycie pakietu danych.</p>