LLLily LeeResume
Back to Projects

Reverse Engineering Crumbl's Web Architecture

Jan 2025 – Present

Reverse engineered Crumbl's production architecture to understand how a high-traffic consumer brand structures performance, routing, and data delivery at scale.

For this project, I reverse engineered the production architecture of Crumbl's website to understand how a high-traffic consumer brand structures performance, routing, and data delivery at scale.

1. Framework & Hosting Architecture

Through network inspection and response headers, I identified: - Framework: Next.js (Pages Router) - Hosting: Vercel - CDN Layer: Cloudflare - Rendering Strategy: Static Generation with Incremental Static Regeneration (ISR)

The presence of routes like `/_next/data/{buildId}/en-US/stores.json` confirms the use of Next.js' data routing system for statically generated or ISR-backed pages. Response headers such as `cache-control: public, max-age=14400`, `x-vercel-cache: HIT`, and `cf-cache-status: REVALIDATED` indicate that certain pages (e.g., store listings) are cached for 4 hours and revalidated periodically, suggesting ISR rather than fully dynamic server-side rendering.

2. Route Prefetching Strategy

The site uses Next.js automatic route prefetching. When hovering over navigation items (e.g., "Order", "Stores"), Next.js prefetches the corresponding `/_next/data/...` JSON routes. This improves perceived performance by fetching route data in advance, caching JSON responses in memory, and enabling instant client-side transitions—triggered automatically via `<Link>` prefetch behavior in production builds.

3. SSR + Hydration Model

On initial page load: the server renders HTML, a large JSON payload is embedded or fetched, and the client hydrates using that data (from `getStaticProps` or `getServerSideProps`). This allows SEO-friendly server-rendered HTML, fast client-side navigation, and CDN-cached static responses.

4. Performance Tradeoffs Observed

Because Next.js embeds or references large JSON payloads for hydration, initial HTML size can grow significantly and large JSON payloads increase transfer size. Excessively large embedded data can negatively impact SEO and page performance—a common SSR tradeoff: faster navigation and hydration vs. heavier initial payload size. In high-content pages (e.g., menus, store lists), careful data shaping is critical.

5. Data Modeling Insights

From inspecting menu JSON responses, I identified rich product domain modeling (nutrition, allergens, images, stats, reviews), structured nested objects (GraphQL-style schema), aggregated stats separated from reviews, and composite review IDs suggesting possible NoSQL or event-style key patterns. This suggests a mature domain-driven design with clear separation between product metadata, user-generated content, aggregated statistics, and notification systems.

6. Architectural Summary

Crumbl's website demonstrates: static generation for scalability, ISR for time-sensitive updates (e.g., weekly menu), CDN edge caching via Cloudflare, client-side route prefetching, React hydration using JSON data files, and separation between public content and account-based flows. The overall architecture prioritizes fast navigation, global caching, SEO compatibility, and scalable content delivery.

Next.jsISRVercelCloudflareSSRReact HydrationCDN