Wp-rocket: Force font-display: swap for CSS minify/combine
Currently we only add font-display:swap if no font-display descriptor has been specified.
This means that when a plugin/theme has set a less optimal font-display, the customer will still see the PSI recommendation to: "Ensure text remains visible during webfont load"
Could we have a filter to _replace_ another font-display with swap so that the customer could still resolve this recommendation?
Examples:
webtrainingwheels
All 6 comments
What about directly force the value without a filter? What could be the reasons to use another value?
GeekPress
on 1 Dec 2020
On whether to provide a filter for other font-display options, some users may be concerned about a flicker effect:
See https://stackoverflow.com/questions/56537360/google-font-display-swap-strange-behaviour
Customers who have a lot of traffic over slow connections may also be concerned about swapping fonts because the swap could take place a longer time later, see
https://calendar.perfplanet.com/2020/a-font-display-setting-for-slow-connections/
That said, when our whole issue is making it faster, I'd guess these would be edge cases for the vast majority of our customer base, but a few might want the filter to prevent being forced into it.
The upshot, having a filter might not be much used, but it's not so hard to add it for the few who might feel strongly about it.
@GeekPress , your call here! :)
iCaspar
on 3 Dec 2020
Grooming Notes:
✅ Reproduce: Current behavior is as previously intended -- to _not_ replace font-display property when it has been already set in the CSS.
✅ Cause: We have intentionally skipped modifying font-display when it is set (see inc/Engine/Optimization/CSSTrait::apply_font_display_swap() and inc/Engine/Optimization/GoogleFonts/AbstractFGOptimization)
✅ Scoped Solution:
- Remove the bypassing guards in each of these classes ~(or possibly add a filter
rocket_allow_defined_font_displayto indicate whether to use the guards)~ - Update tests to reflect the desired new behavior.
✅ Effort estimate: [S]
iCaspar
on 3 Dec 2020
camilamadronero
on 4 Dec 2020
@iCaspar Sorry for the late response.
With Core Web Vitals coming in May 2021, our users are going (if it's not already the case ^^) to be more focused on PageSpeed Insights.
The « Preload key requests » recommendation is the top #1 in priority to do when it's not done. We can be sure that the majority of our users will prefer to get a better grade even if it could have a flicker effect. That's the power of Google, if Google says to do something, even if there is a con, people will do :)
Having a filter is an open door to have a 3rd party changing our swap value. Let's see first if we will have complaints about the default swap value, and then we will iterate by adding a filter is needed.
GeekPress
on 8 Dec 2020
Thanks for the explanation @GeekPress. Edited the grooming above to reflect your comment.
iCaspar
on 8 Dec 2020
Related issues
piotrbak
·
4Comments
crystinutzaa
·
4Comments
vmanthos
·
5Comments
Tabrisrp
·
5Comments
engahmeds3ed
·
4Comments
Most helpful comment
@iCaspar Sorry for the late response.
With Core Web Vitals coming in May 2021, our users are going (if it's not already the case ^^) to be more focused on PageSpeed Insights.
The « Preload key requests » recommendation is the top #1 in priority to do when it's not done. We can be sure that the majority of our users will prefer to get a better grade even if it could have a flicker effect. That's the power of Google, if Google says to do something, even if there is a con, people will do :)
Having a filter is an open door to have a 3rd party changing our swap value. Let's see first if we will have complaints about the default swap value, and then we will iterate by adding a filter is needed.