Current time: 12-16-2017, 09:40 AM Hello There, Guest! (LoginRegister)

Post Reply 
 
Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Understanding the start render
10-18-2012, 04:40 AM
Post: #1
Understanding the start render
Hi guys,

I made some tests with Javascript inclusion into a web page, and I used WPT for this.

See this test case : http://www.webpagetest.org/result/121016...1/details/

I don't understand one thing: If the "Start render" green bar means: "The Start Render time is the first point in time that something was displayed to the screen.", why see I the content before (at 0.5s)?
OK I understand that content is displayed at the vertical pink bar, but in this case, what's the meaning on the green bar ?

Thank you!

PS: Sorry for my english, I'm french Blush.
Find all posts by this user
Quote this message in a reply
10-18-2012, 10:48 PM
Post: #2
RE: Understanding the start render
what content do you see at 0.5s? The HTML file has loaded but that's about it. The content is not "displayed" at the vertical pink bar. The pink bar is when the browser fired the DOMContentReady event (which actually looks wrong in this case).

Requests 2-4 (css and js) are all blocking content in the head of the test page so the browser can't render anything to the screen (or even build the DOM) until it has finished loading, parsing and executing them.
Visit this user's website Find all posts by this user
Quote this message in a reply
10-19-2012, 12:52 AM
Post: #3
RE: Understanding the start render
Thx for your reply.

I show you a screen from Chrome devtools : http://imageshack.us/photo/my-images/411...64106.png/

As you can see, the document is visible just right after the first line (it's the equivalent of your pink vertical bar). The screen is NOT blank until the last script is loaded.
Find all posts by this user
Quote this message in a reply
10-19-2012, 01:04 AM
Post: #4
RE: Understanding the start render
How can I tell that the document is visible right after the first line? The page (as-displayed) includes the image and other elements that haven't been loaded yet so that isn't what is actually presented on the screen.

Sorry, I just noticed that the scripts are async so they aren't what is blocking the UI (directly) but the loading of the css is and in the test you ran the css is competing with the javascript and a few of the images for the available bandwidth.

If you go to the video tab in the advanced settings you can enable video capture of the browser loading and watch to see what happens. I can guarantee that nothing will be displayed until after the css has been loaded (it blocks the render tree but not the dom tree which is why domcontentready fired so quickly).
Visit this user's website Find all posts by this user
Quote this message in a reply
10-19-2012, 04:44 AM
Post: #5
RE: Understanding the start render
Ok, you're right. The content is displayed at the green vertical bar.
I discovered the video option, it's very nice, thanks!

So, the pink vertical bar means that the DOM is builded, but not necessary shown. So, this bar means that, from this time, Javascript can access safety to the DOM and manipulate it. That's right ?
Find all posts by this user
Quote this message in a reply
10-19-2012, 04:56 AM
Post: #6
RE: Understanding the start render
Yes, the pink vertical bar is the domcontentready event ($(document).ready() in jquery). It means the browser has finished parsing the HTML and has built the DOM. Technically it builds as it goes so inline javascript can manipulate anything above it but it's a good thing to look for if you want your async javascript to manipulate the DOM.
Visit this user's website Find all posts by this user
Quote this message in a reply
10-19-2012, 05:46 AM
Post: #7
RE: Understanding the start render
OK, thank you very much for your complete explanations!
Find all posts by this user
Quote this message in a reply
10-27-2012, 12:12 AM
Post: #8
RE: Understanding the start render
Hi Patrick,
Is it possible to track the start render time directly on a page with an event or something like that ?
How did you managed to do it ?
Thanks for your explanations,
Find all posts by this user
Quote this message in a reply
10-27-2012, 01:01 AM
Post: #9
RE: Understanding the start render
Not in the same way that WebPagetest does it. WebPagetest uses binary code that it injects into the browser process and intercepts function calls to the OS for when the browser draws to the screen.

That said, IE 9+ and Chrome do have their own versions of a first paint event that are available to javascript.

For IE it is in window.performance.timings.msFirstPaint - http://msdn.microsoft.com/en-us/library/...s.85).aspx

For Chrome it is in window.chrome.loadTimes().firstPaintTime

Both are relative times to a start time that are within the same objects. I can't guarantee that they report the same as WebPagetest does though, it's possible that they could be reporting the paint of an all-white background for example (which WebPagetest excludes and waits for real content) but it's the best you can do from javascript.
Visit this user's website Find all posts by this user
Quote this message in a reply
02-24-2015, 03:32 AM
Post: #10
RE: Understanding the start render
Hello,
We are plotting start render and first paint for some of our pages and I have noticed that huge DOM pages (~20k nodes) show a strong difference between start render vs first paint whereas pages with a normal DOM size show almost no difference.
As I understand it and given the actual name of the metrics, start render is the beginning of the render phase when CSSOM and the DOM are combined into the render tree, whereas the first paint happens after the render tree and layout stage when the browser actually paints something on the screen.

Can someone clarify/confirm the above?

Thanks
Find all posts by this user
Quote this message in a reply
Post Reply 


Forum Jump:


User(s) browsing this thread: 1 Guest(s)