Duration: 18:53
🧾 Analytical Summary
⚡ The Performance Challenge
Cedric, JavaScript framework product owner, demonstrates how Odoo achieved "blazing fast" performance through aggressive browser storage utilization. A simple contact list view hides enormous complexity: menus, system tray, control panel, view structure, and record data—all requiring server round-trips that slow user experience, especially on poor networks or with large datasets.
📊 Performance Expectations
Under 10,000 elements: Instantaneous (blink-of-an-eye)
10,000-100,000 elements: Acceptable load time (depends on hardware)
Over 100,000 elements: Problems emerge—requiring optimization strategies
💾 Browser Storage Strategy
Odoo leverages IndexedDB for persistent, high-capacity storage (up to 80% of hard drive on Chrome). This dramatically outperforms LocalStorage (5MB limit) and SessionStorage (tab-scoped). The strategy: cache RPC responses rather than replicating entire database schemas.
Why RPC caching? Storing raw data requires reimplementing ORM and business logic in JavaScript, maintaining database schemas, and handling massive data volumes. Caching RPC responses is simpler—web client doesn't care if data comes from server or cache—and collects only needed data in real-time.
🔐 Security
All cached data is encrypted using AES-GCM. Users must be logged in to decrypt—preventing malicious access to browser-stored business data.
🎯 Scope & Limitations
Window actions only (not server/client actions yet)—Field Service and CRM requiring server actions won't benefit until conversion to window actions.
Views supported: Kanban, list, form (pivot/graph/reporting views under consideration).
Cached RPCs: get_views, web_search_read, web_read, onchange, plus custom RPCs added case-by-case.
Opt-out available: Disable data caching per-action while still benefiting from view/menu/translation caching.
🌐 Demo: Offline Capability
Dramatic demonstration: Throttle network to 3G, open contacts (slow), open individual contact (slow), browse next contacts (slow). Return to menu, reopen contacts: instant. Open first contact: instant. Navigate: instant. Previously unvisited contact: slow again (not cached).
Go offline entirely: Contacts still load, browsing works perfectly—only uncached records fail to open. This preview future offline mode capabilities.
🔄 Cache Strategy
First load: Display cached data immediately while simultaneously fetching fresh data. Update screen if changes detected—may cause flicker on slow networks.
Cache invalidation: Refresh empties cache, any customization empties user cache.
Menus: Currently LocalStorage, moving to IndexedDB in 19.1.
Translations: Stored in LocalStorage—all i18n strings cached locally.
🚀 Future: Proof-of-Concept Offline Mode
"Populate cache" feature pre-fetches all visible records. Going offline after population enables full browsing of fetched data—major step toward comprehensive offline functionality. Next phases: enable small edits, sync when reconnecting. Roadmap not finalized, but "come back next year to see progress."
💬 Key Insights
Browser storage is incredibly powerful for UX improvements. Making Odoo fast improves user experience fundamentally—slow software creates bad experiences regardless of features. This work foundations future offline mode, critical for field service, retail, and connectivity-challenged environments.
🧠 Viewpoint: Odoo Perspective
⚠️ Disclaimer: AI-generated creative perspective inspired by Odoo's vision.
This represents the kind of foundational infrastructure work that users rarely notice until it's missing—then they can't live without it. Caching RPC responses rather than reimplementing business logic shows architectural pragmatism: leverage existing backend intelligence, don't duplicate it. The offline proof-of-concept hints at where we're heading: Odoo as true progressive web app, working seamlessly regardless of connectivity. Performance isn't a feature—it's the foundation enabling every other feature to shine.
🏢 Viewpoint: Competitors (SAP / Microsoft / Others)
⚠️ Disclaimer: AI-generated fictional commentary. Not an official corporate statement.
Aggressive browser caching improves perceived performance but introduces complexity around data freshness, conflict resolution, and cache invalidation—problems enterprises know intimately. The "flicker" acknowledged when slow networks return updated data highlights inherent tension between instant response and accuracy. Offline mode viability depends on sync conflict resolution—trivial for read-only scenarios, complex when multiple users edit offline. Still, the UX improvement for connectivity-challenged scenarios (retail, field service) is substantial and worth the engineering investment. Every platform wrestles with these tradeoffs.
Disclaimer: This article contains AI-generated summaries and fictionalized commentaries for illustrative purposes. Viewpoints labeled as "Odoo Perspective" or "Competitors" are simulated and do not represent any real statements or positions. All product names and trademarks belong to their respective owners.