https://klikukliku.dev/pl/tags/bundling/Recent content in Bundling on Kliku KlikuHugoplTue, 27 Jan 2026 00:00:00 +0000https://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-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>