Diagnose slow Time to First Byte on managed WordPress hosting

A site on WP Engine is scoring a 1.8s Time to First Byte in GTmetrix, even though the
page caching plugin reports a 95% cache hit rate. GTmetrix's waterfall shows the HTML
document itself taking that long before any assets even start downloading.

STACK: [Astra theme, Advanced Custom Fields Pro, WPML, WooCommerce, no Redis Object
Cache plugin currently installed]
HOSTING: [WP Engine, business plan, PHP 8.1, page cache handled by the platform not a
plugin]
OBSERVATIONS: [logged-out visitors also get the slow TTFB on some pages; homepage is
fast, but single product pages are slow; WPML is running on 4 languages]

Reason through this like a WordPress performance consultant, not by restating the
numbers:
1. Explain why a high page-cache hit rate and a slow TTFB aren't contradictory here,
   name the likely reason product pages specifically bypass full-page cache (WPML
   language-switcher logic or a WooCommerce cookie forcing a cache miss on those
   templates).
2. Identify what's most likely burning PHP execution time before the cache check
   even completes: ACF doing repeated get_field() calls without object caching, or
   WPML's string translation lookups hitting the database on every request.
3. Give the concrete fix: installing and configuring an object cache (Redis via a
   plugin like Redis Object Cache, if WP Engine's plan includes it), or a code-level
   fix like wrapping repeated ACF calls in wp_cache_get()/wp_cache_set().
4. Separate fixes doable from wp-admin (activating an object cache plugin, adjusting
   WPML settings) from ones that require a WP Engine support ticket (enabling their
   Redis add-on, checking PHP worker limits, reviewing server-level slow query logs).
5. Flag the edge case: if WP Engine's PHP workers are maxed out during traffic spikes,
   no amount of caching plugin tuning fixes TTFB, that's a plan-tier or worker-count
   problem only their support team can resolve.