Jak zbudowałem lekką, szybką i zautomatyzowaną porównywarkę kont firmowych

W świecie webu łatwo zauważyć pewien schemat: nawet proste projekty z czasem obrastają warstwami. Framework na frameworku, kilka systemów analitycznych, rozbudowane buildy, zależności, które żyją własnym życiem. W pewnym momencie więcej energii kładzie się na utrzymanie infrastruktury niż w rozwój samego produktu.

Chciałem zbudować serwis z możliwie prostą architekturą: szybki, łatwy do utrzymania i odporny na codzienne zmiany w ofertach banków. Jednocześnie miał dostarczać przedsiębiorcom aktualnych danych o kosztach, funkcjach i warunkach promocji, zamiast kolejnej strony wypełnionej reklamami.

Tak powstał serwis konta-dla-firm.pl. Projekt wykonany z najlepszymi praktykami technicznymi, dopracowany w niemal każdym calu i jednocześnie bardzo praktyczny przykład tego, że lekkość, automatyzacja i prostota naprawdę mogą iść w parze. Użytkownik otrzymuje aktualne dane, bez wszechobecnych reklam.

Skąd wziął się pomysł

Przeglądając istniejące porównywarki kont firmowych, szybko zauważyłem powtarzalny zestaw problemów: ciężkie skrypty, wolne ładowanie, agresywne reklamy i popupy z długą listą „partnerów” do zgód cookie.

Znając rynek finansowy oraz techniczne aspekty porównywarek wiedziałem, że logika takiej strony jest znacznie prostsza, niż sugeruje cała otoczka.

Pomyślałem więc: a co, gdyby zrobić to jak statyczny serwis — ale z danymi zawsze aktualnymi? Bez paneli, bez analityki i bez rozbudowanego stosu aplikacyjnego i panelu, które wymagają stałego utrzymania.

Prosta architektura i pełna automatyzacja

Cały projekt od początku był projektowany z myślą o prostocie i przewidywalności. Backend jest tak lekki, jak się da — jego główną rolą jest pobranie danych z API oraz z własnego monitoringu ofert (o którym piszę w kolejnym wpisie), ich normalizacja i zapis do pliku cache w postaci JSON oraz wyodrębnienie parametrów istotnych dla rankingu oraz sortowanie ofert. Bez ORM-ów, bez warstw pośrednich i bez "magii". Czysty PHP, który realizuje kilka jasno określonych zadań.

Strona działa wyłącznie na pliku cache JSON. Jeśli API ma chwilową przerwę lub zwraca błędy, użytkownik nadal widzi ostatnią poprawną wersję danych, a serwer nie wykonuje żadnych zbędnych operacji. To podejście upraszcza całą ścieżkę danych i eliminuje wiele potencjalnych punktów awarii.

Kluczowym elementem automatyzacji są Cloudflare Workers. To one uruchamiają cykliczne aktualizacje danych (harmonogram cron uruchamiający aktualizację co 24 godziny) wywołując dedykowany endpoint aktualizacyjny, generują sitemapę, serwują wybrane zasoby z edge i zdejmują z backendu wszystko, co nie musi się na nim dziać. Dzięki temu system jest w dużej mierze automatyczny i reaguje szybko nawet przy większym ruchu.

Frontend rankingu pozostaje maksymalnie przewidywalny: serwer renderuje statyczny HTML, a CSS jest osadzony bezpośrednio w head. Bez frameworków JavaScript, bibliotek interfejsu, fontów z CDN. Zewnętrzne usługi są wykorzystywane wyłącznie tam, gdzie mają uzasadnienie — w automatycznej aktualizacji danych i obsłudze infrastruktury edge.

Cache i wydajność w praktyce

Częścią tej samej filozofii jest sposób obsługi zasobów statycznych, w szczególności logotypów banków. To element, który w wielu serwisach bywa bagatelizowany, a potrafi generować niepotrzebne opóźnienia i zależności od zewnętrznych serwerów. W przypadku instytucji finansowych aktualność i poprawność identyfikacji wizualnej ma znaczenie wizerunkowe.

Logotypy są serwowane przez dedykowany mechanizm działający na brzegu sieci Cloudflare (edge) — czyli możliwie najbliżej użytkownika, a nie na głównym serwerze aplikacji. Oryginalne pliki są pobierane tylko raz na dobę, a następnie cachowane i dostarczane z lokalizacji geograficznie najbliższej przeglądarce. Dzięki temu obrazy ładują się praktycznie natychmiast, a całość pozostaje pod pełną kontrolą — zarówno pod względem wydajności, jak i zgodności z aktualnymi wytycznymi instytucji finansowych.

Ten sam minimalizm przekłada się na ogólną wydajność serwisu. Brak trackingu, brak ciężkich bibliotek, jeden request do danych, statyczny HTML i agresywne cachowanie sprawiają, że przeglądarka ma naprawdę niewiele pracy. Wysokie wyniki wydajnościowe (100/100 w PageSpeed Insights) są tu naturalnym efektem architektury, a nie celem samym w sobie.

Prywatność bez kompromisów

Na stronie nie ma cookies marketingowych, analityki, fingerprintingu ani żadnych skryptów śledzących. Wdrożone są sensowne nagłówki bezpieczeństwa: HSTS, X‑Frame‑Options i restrykcyjna polityka referrerów.

Użytkownik dostaje tylko treść — i nic poza tym.

SEO i przewidywalność

Chociaż serwis działa jak strona statyczna, od początku był projektowany tak, aby był w pełni czytelny dla wyszukiwarek. Dane strukturalne, metadane i sitemapa aktualizują się automatycznie wraz z cache’em, bez ręcznego nadzoru i bez dodatkowych narzędzi.

Układ HTML jest prosty i logiczny, więc roboty indeksujące nie muszą zgadywać, co jest czym. To nie jest "sprytne SEO" ani walka o algorytmy — po prostu poprawna techniczna implementacja, która nie wymaga ciągłej uwagi.

Gotowość na rozbudowę

Projekt powstawał etapowo, najpierw na własne potrzeby, ale z myślą o tym, żeby mógł ewoluować. Po sprawdzeniu logiki działania postanowiłem udostępnić go wszystkim. Logika filtrowania jest na tyle odseparowana, że rozszerzenie porównywarki o inne produkty finansowe dostępne w API (konta osobiste, lokaty itp.), sprowadzałoby się głównie do zmiany parametrów danych i etykiet na froncie.

Kilka obserwacji z produkcji

Jak to zwykle bywa, nawet lekka i niewinna strona szybko zaczyna przyciągać automatyczny ruch. W logach pojawiały się próby wejścia na typowe ścieżki CMS‑ów i frameworków (/wp-login.php, /.env, /xmlrpc.php).

Postanowiłem przetestować reguły "Security rules". Powstały reguły blokujące m.in na user-agent, kraj pochodzenia ruchu, typy plików i ścieżki (path). Filtrowanie ruchu i JS Challenge sprawiły, że backend praktycznie nie widział tego „szumu sieciowego”.

Dodatkowo e‑mail w domenie obsługiwany jest przez Cloudflare Email Routing, co ogranicza ekspozycję infrastruktury do minimum.

Dygresja o luce bezpieczeństwa w React

Od 4 grudnia z zainteresowaniem obserwowałem rozwój sytuacji wokół luki RCE w React (CVE‑2025‑55182), która postawiła na nogi administratorów i zespoły techniczne dużych serwisów.

Mój projekt sam w sobie nie miał powierzchni ataku, której dotyczył problem — brak Reacta, brak runtime’u po stronie użytkownika i brak zewnętrznych zależności zrobiły swoje. Rykoszet jednak i tak mnie dosięgnął.

W trakcie reagowania na CVE Cloudflare aktualizował reguły swojego WAF‑a, aby chronić użytkowników korzystających z podatnych stacków. W praktyce oznaczało to, że przez moment ubita została część zupełnie legalnego ruchu. Nie złośliwie — raczej w ramach szerokiego, defensywnego cięcia.

Sytuacja szybko się uspokoiła, reguły zostały doprecyzowane, a ruch wrócił do normy. Dla mnie była to bardziej ciekawa obserwacja niż realny problem, ale też kolejne przypomnienie, że im bardziej złożony ekosystem wokół, tym większa szansa na skutki uboczne — nawet w prostych projektach.

Podsumowanie

Powstała strona, która robi dokładnie to, czego potrzebowałem: wyświetla aktualne oferty, działa szybko, nie śledzi użytkownika i praktycznie nie wymaga obsługi.

To projekt, który okazał się świetnym poligonem do pracy z edge i automatyzacją, a przy okazji dowodem, że w wielu przypadkach prosta architektura wygrywa z rozbudowaną. Jest lekki jak statyczny serwis, elastyczny jak aplikacja i gotowy na dalszą rozbudowę — dokładnie tak, jak chciałem.