Full-page cache, catalogue output and browser work
In particular, measure filters, variant selection and shopping cart. Extensive extensions can block interactions even though the first page response is fast.
Distinguish slow server responses from extensive theme/extension work in the browser. A warm full-page cache can provide a quick HTML retrieval, although variant selection or filters are slow to respond afterwards.
Where to check the setting in Magento
Compare cache hit and cache miss of the affected storefront page. After that, check the specific browsing work of galleries, filters and third-party scripts. A fast full-page cache does not automatically fix a sluggish interaction after loading.
Example of this specific finding
Illustrative control case: A click on the variant filter waits for a long JavaScript task before a visible reaction appears. The delay concerns a concrete interaction.
follow-up audit in Magento
Test comparable product and category pages under documented cache condition. Price, stock and personal content must not be obsolete or mixed by an optimization.
Repeat the problematic interaction in the performance trace, split up long tasks and reduce unnecessary work. Then measure the same interaction again.
Derogations and scope
INP is not a pure charging time code. A fast first side structure does not preclude slow later operation.
Reference: Magento Open Source or Adobe Commerce with classic storefront. Consider store views and extensions; other storefront architectures have their own configurations.
Classify the general error
Definition, system-independent causes and further correction examples: Name the slow interaction concretely