You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The conclusion in short, this solution doesn’t seem helpful for the WeCount site.
The reason: the .woff and .woff2 files used by WeCount site are already fairly small. Each first stage font file generated by running pfftsubset, suggested in the article, is only 5-7K smaller than ones that are already used on the WeCount site.
Using the regular Fira Sans font file as an example, all sizes are:
.woff2 that is used on WeCount site: 21K
.woff2 generated for the first stage loading: 14K
.woff2 generated for the 2nd stage loading: 128K
I believe the 2nd stage file suggested by the article is much larger is because it includes all layout features. Some of them may not be included at generating the WeCount file.
So, for now, I will take the other suggestion to load font files using “swap”.
Is your feature request related to a problem? Please describe.
Right now, the website is using "font-display: optional" with preloading all font files to gain the best user experience but sacrificing the performance. See the performance test result with preloading all font files.
A common recommended way for font loading is to use "font-display: swap" that doesn't provide the best user experience but has better performance.
@greatislander also found a different method that loads font files in two phases to improve the user experience without sacrificing the performance.
It would be worthwhile to run tests against these three scenarios:
To compare their implementation complexity, effects on loading time at slow connection, and lighthouse reports.
The result will benefit all website developments in overall.
The text was updated successfully, but these errors were encountered: