Why I Extended Apollo Cache Persist with Lazy Per-Query Loading

Our app was getting slower on reload. Not dramatically — just that familiar sluggishness we'd always chalked up to network latency. Then one day I actually profiled a page reload and saw the real cause: the entire Apollo cache was being loaded into memory at startup, before a single component had rendered. Data from a dozen different sections of the app — all of it dumped into memory at time zero. The user had just logged in. The homepage needed none of it. I was already using apollo-cache-persist — a great library that does exactly what it says. The problem wasn't the library, it was the persistence model itself. So I used it as a baseline and built a different approach on top of it: apollo-lazy-cache-persist . The Problem with Traditional Apollo Cache Persistence apollo-cache-persist works by serializing the entire InMemoryCache and saving it to storage. On startup, it reads that snapshot back and restores everything at once. For small apps, this is fine. For larger apps — SaaS dashb