Khichdi InfoTech
Skip to content

Odoo Performance · intermediate · 9 min read

Improving Website Performance

Speed up Odoo website and eCommerce: asset bundles, CDN, image optimization, route caching, and separating storefront load from back-office workers.

Last reviewed 2026-07-30 · Estimated effort: 2–6 weeks typical implementation slice

Table of contents

Odoo website performance spans browser asset delivery, server-side rendering of QWeb routes, ORM cost on product and pricelist queries, and session handling under marketing traffic spikes.

Heavy JavaScript bundles, unoptimized product images, and shop controllers that search large catalogs on every page view hurt Core Web Vitals even when back-office screens feel acceptable.

Separate concerns: CDN and compression for static assets, caching for anonymous catalog pages, ORM and index fixes for shop queries, and worker or rate limits so flash sales do not starve warehouse users.

Marketing measures Lighthouse scores while operations reports slow picking — both can be true. Website routes share the same Odoo workers and database as ERP users unless architecture deliberately isolates them.

This article focuses on Odoo website and eCommerce speed. Pair with caching strategies for HTTP layers and with Shopify integration articles when the storefront is external but Odoo still serves snippets or portal pages.

Audit website asset bundles: defer non-critical JS, remove unused theme modules, and minimize third-party widgets on checkout paths. Product images should use appropriate resolution and modern formats — not full-size attachments on category grids.

Serve static assets from CDN or a dedicated static hostname with long cache headers. Version hashes on assets prevent stale cache after deploys.

  • Compress and resize product media at upload or sync time
  • Limit animations and carousels on mobile-first landing pages
  • Review custom JS added via theme snippets on every page
  • Use lazy loading for below-the-fold images

Product listing and search routes execute domains against product.template and related tables. Unindexed filters, expensive pricelist computations, and attribute searches without stored helpers show up as slow category pages.

Reduce per-request query count: prefetch public categories, cache facet counts where business rules allow, and avoid loading full product chatter or unused fields on list templates.

Anonymous catalog and CMS pages are prime candidates for reverse proxy or Odoo website cache where content is not personalized. Cart, checkout, and portal routes must stay dynamic — cache keys must respect session and pricelist context.

See the caching strategies article for CDN, Varnish, and Odoo-specific cache invalidation when products or prices change.

During campaigns, consider dedicated workers or rate limits for /shop routes, or host marketing landing pages outside Odoo when traffic is purely informational. Monitor concurrent sessions versus worker count.

When Shopify or another platform owns checkout, Odoo website load may be lighter — but portal and payment links still need baseline performance testing.

  • Measure product, category, and checkout p95 separately from homepage.
  • Put CDN in front of static assets before rewriting theme code.
  • Index fields used in shop search and attribute filters.
  • Load-test website routes with realistic catalog size on staging.
  • Coordinate price and stock updates with cache invalidation rules.
  • Review Development standards for custom controllers on public routes.

  • !Optimizing only the homepage while category pages timeout.
  • !Caching authenticated portal pages with shared cache keys.
  • !Embedding huge unoptimized PDFs or videos on product tabs.
  • !Running A/B scripts that block render on every shop request.
  • !Sharing one small worker pool between peak web and month-end accounting.
  • !Ignoring mobile network latency when testing from office fiber.

Website performance blends asset delivery, shop ORM efficiency, and infrastructure that protects ERP users during traffic spikes.

Next, implement layered caching with clear invalidation when catalog or pricing changes.

Shop page request from CDN, worker, ORM, and PostgreSQL.
1

Request

HTTP / RPC enters Odoo.

2

Auth & ACL

Users, groups, record rules.

3

ORM work

Reads/writes with business logic.

4

Response

UI, API payload, or job enqueue.

Split traffic: public shop workers vs back-office RPC.
  • Client / Channel

    Users & devices

  • Odoo Application

    Business logic

  • PostgreSQL

    System of record

  • Workers / Cron

    Async work

  • clientapp(HTTP)
  • appdb(ORM)
  • appjobs(queue)

Frequently asked questions

Does Odoo website support full page cache?

Partial and route-level caching is possible with correct configuration and proxies. Personalized pricelist and cart routes need careful rules — anonymous catalog caching is the usual starting point.

We use Shopify for storefront — is this article relevant?

Yes for Odoo portal, payment links, and any remaining website pages. Integration load still affects workers — see Shopify pillar articles for sync performance.

How many workers for ecommerce traffic?

Depends on concurrent sessions, theme weight, and shared back-office load. Load-test with expected campaign traffic plus normal ERP concurrency.

Slow shop or portal pages?

Share catalog size, theme customizations, and peak traffic — we will outline asset, cache, and query improvements.

Business technology and software delivery