Engineering Within Oxygen’s Limits: Avoiding Quota Pitfalls

Introduction

Shopify Oxygen delivers Hydrogen apps at the edge. But Oxygen workers aren’t limitless — they run with strict quotas on bundle size, memory, CPU, and subrequests.

Exceed those limits, and you’ll see failed deploys, timeouts, or spiking TTFB. This post explores Oxygen’s constraints and how to engineer within them.

The Quotas That Matter

• 📦 Bundle size → keep <5MB compressed.
• 🧠 Memory → ~128MB per worker.
• ⏱️ CPU → capped (~30s per request).
• 🔀 Subrequests → ~40 per route.

👉 Think of Oxygen like a Formula 1 car: blazingly fast, but only if tuned precisely.

Impact of Quota Violations

• ❌ Failed deploys → oversized bundles rejected.
• ❌ Cold start latency → bloated workers take 300ms+ longer to spin up.
• ❌ Runtime crashes → memory-heavy SDKs blow through 128MB.
• ❌ SEO risk → slow TTFB drags rankings.

Guardrails for Developers

Slim Bundles

• Tree-shake libraries.
• Replace Node-only packages.
• Lazy-load heavy SDKs with dynamic imports.

Respect Subrequest Budgets

• Batch GraphQL queries.
• Use defer() for secondary data.
• Cache aggressively at edge.

Avoid Node-Only APIs

• No fs, crypto, or heavy polyfills.
• Use edge-safe equivalents.

Observability

• Use profiler logs to track memory/CPU.
• Monitor TTFB budgets in CI/CD.

Case Example: Lifestyle Retailer

• Original PDP worker: 9MB bundle, 70+ subrequests.
• Deploys failed, TTFB ~500ms.
• Fixes: slimmed bundle, batched GraphQL queries, cached PLPs.
• Final: 3.5MB worker, 32 subrequests, TTFB ~220ms.

Agency Deliverable

Turn Oxygen quota compliance into a billable audit service:

• “Quota Health Report” for merchants.
• CI/CD setup with quota enforcement.
• Upsell ongoing performance monitoring.

Conclusion

Oxygen is powerful — but only if you stay within its limits. By slimming bundles, managing subrequests, and enforcing guardrails, Hydrogen apps stay fast, stable, and globally scalable.

Quotas aren’t constraints — they’re design parameters.