Wstę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: Self-Hosting Cusdis na VPS.

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.

Cusdis w praktyce#

Cusdis jest zaprojektowany jako minimalistyczny, osadzany widget komentarzy dla małych stron, w tym blogów statycznych. W praktyce dostajemy komentarze bez obowiązkowego logowania po stronie użytkownika, a projekt deklaruje brak użycia cookies, co dla wielu osób jest kluczowe w kontekście prywatności i compliance.

Z perspektywy produktu widać tu konsekwencję: autorzy kładą nacisk na mały SDK (rzędu kilku kilobajtów po gzip), wbudowane i18n oraz wsparcie dark mode, zamiast rozbudowanych „platformowych” funkcji. Jest też temat operacyjny: Cusdis oferuje powiadomienia e-mail o nowych komentarzach i mechanizmy szybkiej moderacji z poziomu linku w mailu, co realnie skraca czas reakcji.

Integracja z Hugo#

Zamiast wrzucać kod w szablon „na sztywno”, poszedłem w partial, bo to daje mi kontrolę nad parametrami z hugo.toml i pozwala łatwo przenosić konfigurację między środowiskami. Dzięki temu, kiedy zmieniam host lub App ID, nie dotykam warstwy widoków.

Plik layouts/partials/comments/cusdis.html zostawiłem w formie możliwie neutralnej, z parametrami strony (URL, tytuł, unikalny identyfikator), bo to właśnie one decydują o tym, czy wątek komentarzy będzie poprawnie „przypięty” do konkretnego wpisu.

{{- $cusdis := .Site.Params.cusdis -}}
{{- $lang := .Site.Language.Lang | default "en" -}}

<div id="cusdis_thread"
  data-host="{{ $cusdis.host }}"
  data-app-id="{{ $cusdis.appId }}"
  data-page-id="{{ .File.UniqueID }}"
  data-page-url="{{ .Permalink }}"
  data-page-title="{{ .Title }}"
  data-lang="{{ $lang }}"
  data-theme="dark"
></div>
<script async defer src="{{ $cusdis.host }}/js/cusdis.es.js"></script>

Konfigurację przeniosłem do hugo.toml, żeby dało się ją zmieniać bez przebudowywania layoutów. Wariant self-hosted wskazuje na host gdzie mamy naszą usługę cusdis, a wariant chmurowy po prostu używa https://cusdis.com.

[params]
  commentSystem = "cusdis"

[params.cusdis]
  host = "https://comments.yourdomain.com"  # albo https://cusdis.com dla usługi w chmurze
  appId = "twój-app-id-tutaj"

Żeby zachować porządek w kodzie, dodałem prosty „dispatcher” na poziomie layouts/partials/comments.html. To jest drobiazg, ale w praktyce bardzo ułatwia życie: przełączenie systemu komentarzy to jedna linia w configu, a reszta layoutów pozostaje nietknięta.

{{- $commentSystem := .Site.Params.commentSystem -}}

{{- if eq $commentSystem "cusdis" -}}
  {{ partial "comments/cusdis.html" . }}
{{- else if eq $commentSystem "giscus" -}}
  {{ partial "comments/giscus.html" . }}
{{- else if eq $commentSystem "disqus" -}}
  {{ partial "comments/disqus.html" . }}
{{- end -}}

Wydajność i moderacja#

W testach porównałem baseline (bez komentarzy) z wersją z włączonym Cusdis. U mnie skończyło się to wzrostem z 11 do 15 requestów, transferem +24 KB (311 KB → 335 KB) i czasem ładowania +0.83 s (1.20 s → 2.03 s). Te liczby traktuję jako „mój konkretny przypadek”, bo będą zależeć od cache, kompresji, latencji do hosta i tego, czy mówimy o rozmiarze po gzip czy o transferze raportowanym przez konsole developerską przeglądarki.

To, co doceniłem po stronie operacyjnej, to prostota moderacji: Cusdis przewiduje przepływ, w którym dostaję powiadomienie e-mail o komentarzu i mogę szybko go zatwierdzić, bez przeklikiwania się przez ciężki panel administracyjny. Jeśli hostuję sam, mam też argument infrastrukturalny: dane i kontrola są po mojej stronie, bo Cusdis jest self-hostowalny i z definicji nie próbuje zamknąć mnie w vendor lock-in.

Warto natomiast wiedzieć, że stylowanie bywa mniej wygodne, bo widget renderuje się w iframe — a to ogranicza klasyczne podejście „dopisz CSS w motywie i po sprawie”. W praktyce najczęściej kończy się to albo akceptacją wyglądu dark/light, albo edycją stylów po stronie instancji (przy self-hostingu), ewentualnie własnym JS-em, jeśli naprawdę chcemy dopiąć wszystko do design systemu. Jak wstrzyknąć style do iframe-a przy pomocy js możesz zobaczy tutaj

Kiedy to ma sens#

Cusdis dobrze pasuje do statycznych blogów i stron, gdzie priorytetem jest prostota, mały narzut oraz prywatność, a akceptowalnym kosztem jest ręczna moderacja. Cusdis celowo nie próbuje być „pełnym Disqus”, tylko minimalistycznym, osadzanym systemem komentarzy dla małych serwisów — i jeśli tego szukasz, ta decyzja produktowa działa na jego korzyść.

Jeśli potrzebujesz rozbudowanych funkcji społecznościowych (logowanie social, bogaty edytor, rozbudowane wątki jak w GitHub), to zwykle szybciej dojdziesz do ściany i lepiej od razu rozważyć alternatywy. Natomiast jeśli chcesz mieć komentarze „po prostu”, bez cookies, bez ciężkiego skryptu i z sensownym przepływem moderacji, Cusdis jest pragmatycznym wyborem.