Enhance the way we detect the cached page for lcp beacon script
Before submitting an issue please check that you’ve completed the following steps:
- Made sure you’re on the latest version Yes
- Used the search feature to ensure that the bug hasn’t been reported before Yes
Describe the bug Based on this PR: https://github.com/wp-media/wp-rocket/pull/6610
We agreed to merge it as it is and open another issue to mention the cases we need to handle to enhance this PR's code.
- [ ] We can see in some cases we don't serve cache files mainly as a compatibility with some hosting companies so the cache is served from the hosting company not from our side, for this case we may consider clearing the page cache for the page that its lcp row was updated/created.
- [x] When the constant
WP_ROCKET_WHITE_LABEL_FOOTPRINTis there we still add theDebug: cachedhere and we search for it in the new beacon here So we are fine here - [ ] @MathieuLamiot suggested to use the following strings instead of
Debug: cached:
'<!-- Optimized for great performance'
OR
'<!-- This website is like a Rocket, isn't it? Performance optimized by '
- [ ] Another suggestion is to add a class name or data attribute to any element (html, body, ...etc.) inside the cache file and use it, but again this will work only when we serve our cache (Check first point)
Additional context Add any other context about the problem here.
Acceptance Criteria (for WP Media team use only) Clear instructions for developers, to be added before the grooming
@jeawhanlee mentioned here that sometimes Debug: cache is not present. This is why I suggested instead:
'<!-- Optimized for great performance'
OR
'<!-- This website is like a Rocket, isn't it? Performance optimized by '
I don't know in which case this happens though. Maybe @jeawhanlee can explain? But there is a condition so I guess it can happen that Debug: cached is not there:
if ( ! empty( $time ) ) {
$footprint .= ' - Debug: cached@' . $time;
}
What are the expectations and acceptance criterias for this issue?
@wp-media/product I think this issue would benefit clear use-cases and ACs as I see it is planned for 3.16.4
@MathieuLamiot while looking into this issue it doesn't seem to be a quick win. I thought we're not covering the whitelabel scenario but it's the case already. I don't think we'll have an easy solution here to cover the 3rd-party cache.