-
Notifications
You must be signed in to change notification settings - Fork 210
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fetchpriority of LCP is not applied on the LCP markup when the LCP URL is relative #6604
Comments
Scope a solution ✅
We need to change the either change the pattern to cover both instance which I'm struggling with. However, I came up with the approach below,
Estimate the effort ✅[S] |
I really like using I think converting the url into relative one and adjust the regex a bit to accept any character before the relative url will do the trick. What do u think @Khadreal ? |
Regex would be more suitable, just couldn't it to work. I tried turning the URL to relative but the result weren't great. For example image url like this will fail http://1.gravatar.com/avatar/d7a973c7dab26985da5f961be7b74480?s=120&d=mm&r=g. |
Because of the issue raise in the first solution, I came up with some pointers from @wordpressfan. I created a draft PR. I'll add test foe different cases to make sure it doesn't regress from what we have before now.
|
Before submitting an issue please check that you’ve completed the following steps:
Describe the bug
The LCP feature should add the fetchpriority attribute to the LCP markup.
When the LCP markup contains a relative URL, this is not done. Note that the preload markup is correctly added with an absolute URL and the fetchpriority.
To Reproduce
Steps to reproduce the behavior:
wp-content/rocket-test-data/images/600px-Mapang-test.gif
wp-content/rocket-test-data/images/600px-Mapang-test.gif
image. There is no fetchpriority attribute.If you do the same on http://xxx.e2e.rocketlabsqa.ovh/landing-page/, the attribute is correctly applied.
I think the difference is the absolute/relative paths.
Note that we have similar issues when a CDN is being used: if the URL in the DB contains the CDN hostname, then the fetchpriority is not applied as expected when serving the page.
Expected behavior
If it make sense to tackle this in the same issue (nice to have, otherwise, create a dedicated GH issue):
Additional context
The issue seems to be with
set_fetchpriority
which performs a regex based on the URL we have in the DB. Mismatch between relative/absolute/CDN hostname make the regex fail?Acceptance Criteria
If dealt with in this PR, the same ACs must be checked with the CDN feature enabled and LCP stored in DB with the CDN hostname.
The text was updated successfully, but these errors were encountered: