A first round google interview question I was asked: If you have a web page with two images on it, how many web request will need to be made to render the page? (Assume http 1.1)
I had to ask if he wanted the technically correct answer or the one I bet he (the google recruiter) was given by his engineers. Sadly his google engineers had given him the wrong answer.
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.)
"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.
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.
Maybe they are evaluating how do you answer instead of what do you answer. If your answer includes a total underestimation of the recruiter's knowledge, maybe that's an attitude that google is not looking for.
A previous discussion on HN indicated that at least on some levels they are just checking if the answers match those one that have been provided by somebody:
https://news.ycombinator.com/item?id=12701272
So 1 would be referring to the underlying connection which would be kept alive? Or is the interpretation that the page has "rendered" even before the images has loaded
1 would be with inline images (either in CSS or directly with data URLs), 2 would be 1 HTML and one image sprite, 3 would be just 2 image tags in 1 HTML page.
Good point. I suppose it's presumably async with respect to the render anyway. It looks even more nuanced on pages that have an iframe [1] (though presumably that's not the case here).
I had to ask if he wanted the technically correct answer or the one I bet he (the google recruiter) was given by his engineers. Sadly his google engineers had given him the wrong answer.