I am trying to understand why the Start render in this case is later then the load event.
The Load Event is something coming from the browser, if it’s supported. It’s been known to be an inaccurate metric because other things can still get loaded after this to finish loading a page. And it looks like you have some JS files being requested that are blocking the page from rendering faster as well.
Start Render is a WPT metric that visually determines when a page starts to render onto the screen. So it’s more accurate, and if anything is blocking that render, like a script, you won’t see anything on the screen even though the Load Event was triggered.
I would focus more on the Fully Loaded area, rather than the Document Complete area of the results table, since it’s likely more accurate to what a user may encounter on your site.
Thanks! It starts to make sense… I was sure that something is wrong with that test.
So basically the browser’s load event can fire even while some scripts are still busy runing?
Sounds strange, no?
What would be a good way to see which script it is?
Is the suggested way by blocking script by script in WPT to see which one causes this issue?
Sorry not replying to you sooner.
One way to tell which script may be slowing you down is with WPT itself.
If you see a bunch of scripts at the top of the waterfall, and its taking time for the page to load, I would take a look at those scripts.
But I wouldn’t go the route of blocking them individually. That could take some time to do in WPT, plus doing so would identify more than just performance issues. So I would only do that if I wanted to know about how the site the only performs but looks with or without certain scripts.
To help identify which script may be causing performance issues, I would instead run WPT with the option to capture the Chrome timeline. The Timeline should give you an idea of which scripts are causing problems.