Performance improvements 🔥 🔥 🔥 #1057
Closed
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hi. I wanted to share some ideas about docs performance improvements.
TL;DR:
I have some history, so let's go.
Using pwmetrics some measurements were done.
P.S. It’s taking measurements using Nexus 5 devices emulation and 1.6 Mbps network throttling.
So, looks like there some place for opportunity,
Below some inconsistent behavior of FOIC (flash of invisible content) and FOUC (flash of unstyled content) can be noticed.
FOIC
FOUC
It will be nice to show fallback font as soon as possible and add progressive enhancement strategy to the site.
But, first of all, scripts which are blocking First Paint should be managed.
Timeline trace
So, adding
defer
attribute to all these scripts (except vue.js, we will manage it later) brought us to100ms for TTCI and TTFI not so impressive but it’s something.
Commit - b996ecf
Continue….
Adding defer to
vue.js
saved usFCP -
3,528 sec
->1,972 sec
FMP -
4,627 sec
->3,419 sec
PSI -
6,116 sec
->4,912 sec
TTFI -
6,066 sec
->4,861 sec
TTCI -
6,066 sec
->4,861 sec
Good, but we can do more.
Commit - 97ea5db
P.S. Adding defer requires to warp example codes into domContentLoaded listener, but I think it can be easily done in scope of
hexo-renderer-marked
fork.Looks like fonts loading is blocking FMP
Timeline trace
Since browsers repaint after loading resources founded in body
we can cheat and move loading resources fonts there.
Commit - 7fba6b7
Results:
Really really nice results on chart.
FMP, FCP under
2 sec
TTCI, TTCI, PSI under
5 sec
How it looks in browser
FOIC
FOUC
Not nice behavior for browsers with FOIC strategy…
But, we have fontfaceobserver which detects fonts loading. Let's try it.
So, results are:
Timeline trace
FMP, FCP under
2 sec
, still the sameTTCI, TTCI, PSI under
5,2 sec
instead of4,8 sec
Hense,
400ms
looks like a good trade off for consistent behavior through all browsers.Commit - 6b13c3
And, last gifs
FOIC
FOUC
Aaaaand to compare the before and after...
Thanks :)
P.S. In case supporting only evergreen browsers
font-display
can manage FOIC.