Frontend enterprise często oblewa review wydajności w mylący sposób. UI wygląda na winowajcę, bo to tam widać lag, ale rzeczywistym problemem bywa kontrakt pomiędzy przeglądarką i backendem.
W jednej platformie produkcyjnej przebudowałem widoki dużych zbiorów danych wokół React 18, TypeScript i RTK Query oraz przeniosłem paginację, sortowanie i filtrowanie na serwer. W reprezentatywnych widokach mierzonych Chrome DevTools zużycie pamięci przeglądarki spadło o około 70%.
Najciekawszą częścią nie był sprytny trik z memoizacją. Było nią usunięcie pracy, której przeglądarka nigdy nie powinna była otrzymać.
Tabela jest funkcją rozproszoną
Poważny data grid obejmuje co najmniej cztery warstwy:
- semantykę zapytania w API;
- filtrowanie i sortowanie w bazie;
- tożsamość cache’u po stronie klienta;
- renderowanie i interakcję w UI.
Jeżeli którakolwiek warstwa udaje, że cały dataset to „po prostu local state”, przeglądarka ostatecznie za to zapłaci.
Mierz kształt problemu
Zanim zaczniesz optymalizować komponenty, zmierz:
- rozmiar przesyłanego payloadu;
- retained heap po wielokrotnej nawigacji;
- liczbę zamontowanych wierszy i komórek;
- duplikację requestów;
- czas zapytań API.
To oddziela koszt renderowania od kosztu retencji danych i kosztu backendu.
Zasada praktyczna
Nie optymalizuj komponentu, zanim nie zdecydujesz, czy komponent w ogóle powinien posiadać te dane.
Dla dużych datasetów operacyjnych semantyka zapytań po stronie serwera jest często frontendową optymalizacją o najwyższym ROI.