| raw | raw/how-i-improved-my-apps-performance-10x.md |
|---|---|
| url |
TL;DR: Chris Raroque made Ellie’s calendar feel much faster by copying the cache-first pattern from Notion Calendar: load prior events locally first, fetch fresh server data second, then update only the affected slice of local cache.
Biggest lessons
- Define performance narrowly. The problem was not “make the app faster”; it was “calendar events should load near-instantly when users revisit weeks/calendars.”
- Study faster products. Chris inspected Notion Calendar’s web app and found IndexedDB usage, then tested whether clearing the local database changed load behavior.
- Use cache-first, network-second. Load from IndexedDB immediately, then refresh from the server and update the cache.
- Do not overwrite the whole cache with filtered data. Server responses are usually filtered by time range and selected calendars. Replacing the full local cache with a filtered response would delete unrelated cached events.
- Local data raises debugging stakes. Schema versioning, migrations, corrupted cache writes, clearer errors, and a “clear IndexedDB” button became necessary because bad local data is harder to fix remotely.
- Speed work often improves stability. Revisiting the calendar code also exposed race conditions and other older rough edges.
Why it matters
- This source belongs in app-product-craft because performance is not invisible; it is a core part of product feel.
- It also updates app-tool-stack with a concrete local-cache pattern for React/Electron apps and a Core Data analogue for iOS.
- It supports product-led-growth because self-serve products lose trust when core actions feel slow.