[docs] Use Suspense for lazy loading algolia #17451
Conversation
Details of bundle changes.Comparing: e48aeba...0aa4702
|
|
On this topic of improving the search. It seems that none of the pages under |
eps1lon
force-pushed
the
docs/deferred-appsearch
branch
from
2dce6e5 to
8ebae8f
Compare
| return ( | ||
| <React.Fragment> | ||
| <link | ||
| rel="preload" |
There was a problem hiding this comment.
Should we use prefetch to reduce the priority? https://3perf.com/blog/link-rels/
There was a problem hiding this comment.
As far as I can tell
It’s helpful when you need that resource a few seconds after loading the page, and you want to speed it up.
fits exactly how we're using it currently.
There was a problem hiding this comment.
I have asked because it might delay another resource, a resource that might we might need to get to an interactive state, previously we were waiting for the interactive state to load this CSS asset. Given that we don't need this asset for the first load, we could delay its loading.
I haven't checked the actual implication, It's only a guess.
There was a problem hiding this comment.
I don't know what I'm supposed to do with guesses in a code review. The documentation you linked supports the implementation. If there are more important resources blocked by this implementation it would help if you include what these resources are and why you think they are more important.
Just arguing against an implementation with guesses is not helpful.
There was a problem hiding this comment.
It was an invitation to explore this path. It seems to be confirmed by https://www.webpagetest.org/video/compare.php?tests=190917_YM_74b7ddcba6319bbfca4d7c222ea68345,190917_1H_0ff4283726ec6cfc83b0f994b87f446b. We load the CSS asset before the interactive state. Could it be a misusage of the available resources early in the loading stage?
There was a problem hiding this comment.
Sure, here is the difference I could notice:
branch
master
There was a problem hiding this comment.
But why would you care about the order? The user won't notice. What's important is are user metrics like time to first byte or first meaningful paint or time to interactive. None of these are affected in any meaningful way.
You're looking for any difference and calling it a regression which is obvious since something was changed. What's important is the difference for the user not some theoretical internal difference, no?
Even more so why would you think it's ok for a stylesheet to be loaded after time to interactive? It can display search results without styling.
There was a problem hiding this comment.
The difference is only noticeable on a slow connection: https://www.webpagetest.org/video/compare.php?tests=190920_BS_a465ecd007173c07ecbd9e31fc2e1cf4,190920_D1_023f612a117b19cdd554390950f98104. Assuming we have to prioritize the order in which we load the assets, I believe that the CSS asset is less important because the search to be displayed requires the following steps:
- The page is interactive
- The Algolia JavaScript asset is loaded
- The search is visible
- The user starts a search
We should be able to start loading the CSS assets at 2, and complete it before 4 triggers.
There was a problem hiding this comment.
Anyway, it's not very important, most of our users have a decent connection, move forward as you see fit :)! It would probably only impact synthetic benchmarks.
There was a problem hiding this comment.
I wouldn't understand why an asset with preload would block either the suspended chunk or the page becoming interactive. The whole point of this is to signal to the browser: "no biggy if you don't load this but when you have the time start loading this please". I wouldn't bother too much looking into order of the loads because this changes by nature. You should not bother about the order because a dedicated scheduler does that.
There are too many moving parts here that you can't be sure this is a bad change. There are even some metrics that are better with this change. Another issue is that the time to first byte is already slower in the preload benchmark which surely is just random error that already gives the master benchmark a head start.
Like this is no easy graph to read. You can't just look at two numbers and go: yep that's worse. As I read it this change makes the first interaction possible after 8s down from 9s (red is non-interactive because the main thread is blocked):
master:
preload:
eps1lon
force-pushed
the
docs/deferred-appsearch
branch
from
8ebae8f to
0aa4702
Compare
Instead of eagerly loading the Input and waiting for algolia to load we bundle the input and algolia into a chunk and lazy load that one. It allows us to remove the custom retry logic. Previously we retried every 100ms to initialize the docsearch until runtime dependencies were loaded and markup was initialized. The browser takes care of this now.
Hopefully this also means that the sever rendered landing page has no dependencies on the input component which would reduce the initial size a bit.
Not sure I like the use of the
Skeletoncomponent here.