Hacker News new | comments | show | ask | jobs | submit login

If the question states "to render the page" then it's very likely the answer is about blocking versus non-blocking calls. Images don't block the browser's renderer because they're loaded asynchronously, so the answer is 1. As soon as the browser has fetched the HTML and parsed the header for blocking scripts and CSS it'll build the DOM and render it. The images will be requested during that time, but they won't stop the rendering from happening. The browser will rerender the page as soon as the images load (or sooner if they're progressive JPEGs). The same is true of favicon.ico. That's loaded in the background after the first render.

(I think that's all still true. Browsers move fast.)




I'm not sure I understand your comment. Either way we still need the requests for the images to return (or fail) before we can call the page rendered.


"rendered" is a slightly tricky term when it comes to browsers. Often when people say "rendered" they mean "the page has loaded, all assets are there, and the whole thing has been drawn on the screen", but when someone from Google says "rendered", especially in a job interview, they probably mean the time to the first paint. That happens after all the blocking assets (synchronously loaded javascript, CSS, etc) have loaded but long before all the other assets (images, async JS, etc) have loaded.


That's fair, but agree it is ambiguous the way it's asked.

This front-end doc [1] from Google with a similar example counts a sample page with (1) html, (2) one external css file, and (3) one external image as "a minimum of 2 roundtrips":

> As a result, this page incurs a minimum of two roundtrips before it can be displayed. Once again, the CSS file may take multiple roundtrips, hence the emphasis on "minimum".

> Notice that our "awesome photo" did not block the domContentLoaded event. Turns out, we can construct the render tree and even paint the page without waiting for each asset on the page: not all resources are critical to deliver the fast first paint. In fact, when we talk about the critical rendering path we are typically talking about the HTML markup, CSS, and JavaScript. Images do not block the initial render of the page—although we should also try to get the images painted as soon as possible.

[1]: Analyzing Critical Rendering Path Performance https://developers.google.com/web/fundamentals/performance/c...


Could also embed the images into the CSS itself (or embed them in JS) and thereby get it down to 1 no matter what. There's so much ambiguity in the question. For instance, what constitutes a request? Are we talking just HTTP requests, or should we count things like DNS lookups. There's also unknowns in play that others have mentioned like caching and redirects.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: