Performance
The performance characteristics of a Fenómenus site, and the practices the product itself follows.
Where the cost is
| Operation | Cost profile |
|---|---|
| Rendering a menu archive | One term query plus one item query per rendered term |
| Category navigation | One ordered term query, plus a check for terms with posts |
| Bulk import | One title lookup for the batch, then one write per row |
| Excel export | One unbounded query over the menu type |
| PDF generation | One query per category, plus image resolution per item |
| QR generation | URL resolution per selected destination and language |
The two unbounded operations — export and PDF — are administrative and deliberate.
Ordered term queries
Every ordered listing sorts on the tax_position term meta. Custom code reproducing menu order runs the same query shape, and benefits from the same caching as any other term query.
Item queries
Items are ordered by menu_order. Archive rendering pages the results, and carousel layouts load further batches progressively rather than rendering an entire menu at once.
Custom queries that fetch a whole menu type with posts_per_page => -1 are acceptable in admin tools and inadvisable on the front end.
Static caches
Several helpers resolve settings once per request and reuse the result — the theme's configured post types, the configured taxonomies, and derived label lookups. Call them freely; they do not repeat the work.
Bulk work
Bulk saves defer term counting, suspend cache invalidation, skip edit-screen side effects, resolve every title in one preloaded lookup, and update ordering with a single targeted write per row. The page cache is purged once at the end rather than once per row.
The practical guidance for custom tools is the same, and is documented in Bulk operation cache strategy.
Page caching
A Fenómenus archive is a public page and caches well, with two considerations:
The allergen filter is a query parameter. A filtered archive is a distinct URL, and a cache must treat the parameter as part of the key rather than serving a filtered response to an unfiltered request.
Guest preferences are client-side. The allergen selection, the icon visibility switch and the favorites collection live in the guest's browser, so they do not fragment the server-side cache.
Images
Images are the dominant weight of a photo-led layout. The product does not resize or convert them.
- Upload at the size you intend to publish.
- Keep a consistent aspect ratio so layouts do not reflow.
- For PDFs, choose the loaded image size deliberately: too small prints soft, too large produces a heavy file.
What does not scale silently
- Photo-led layouts on long menus. A masonry grid of two hundred photographed items is a large page.
- A single Excel export of a very large menu. It is one unbounded query and one file.
- A PDF of an entire large wine list. Consider printing a selection.
- Very large single imports. Batch by category, which is also the reviewable unit.
Multisite
Menus, settings, allergen libraries and user profiles are scoped per site. Nothing is shared between the restaurants of a network, and a purge triggered by one site's bulk save applies to that site.
Measuring
When investigating a slow menu, separate the layers:
- The uncached page generation at the origin.
- The cached response.
- The edge, if a CDN is present.
- Image weight, measured separately from HTML.
A cached menu that is fast tells you nothing about the first request, which is what a guest gets after any content change.