---
title: "Pamięć przeglądarki jest cechą produktu"
description: "Duże tabele enterprise nie stają się szybkie tylko dlatego, że szybka jest biblioteka komponentów. Kontrakt danych, kształt zapytań i strategia renderowania muszą być spójne."
publishedAt: "2026-07-20"
draft: false
featured: false
category: "Wydajność"
readingMinutes: 5
tags: ["React", "wydajność", "RTK Query", "DevTools"]
---

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:

1. rozmiar przesyłanego payloadu;
2. retained heap po wielokrotnej nawigacji;
3. liczbę zamontowanych wierszy i komórek;
4. duplikację requestów;
5. 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.