I don't understand how these interviews work. You can't have a single correct answer to these kind of questions.

- 3 seems to be the obvious answer.

- 1 for keep alive stuff but even with a single connection, there are multiple requests. Also, nobody said the images were on the same server.

- Did I have these images on cache? Maybe 1 then.

- 4 with favicon request (now we are nitpicking)

- Hey maybe each resource is behind 5 http redirects.. So 15 would be correct I guess?

- Base64 encoded images are fun too.

They really have a "set in stone correct answer" and do not discuss these with people?

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.

This is being excessive but... the images could be no requests if they are embedded on the page as Data URIs [1], or if they are SVGs.

I wonder if there is a single "correct" answer.

[1] http://caniuse.com/#feat=datauri

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

You can do one request if you embed the picture into the html document: https://en.wikipedia.org/wiki/Data_URI_scheme

Don't really understand why either 1 or 3 would be incorrect answers. But then again... I don't work at Google.

So, which were yours and their answers? I'd say usually 3, but you could do 1.

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.

You can always inline your images.

I'll bite. Why is "3" the wrong answer?

Because a complete rendering of the page includes fetching /favicon.ico.

If there even is a favicon... and if a .ico file is considered an "image".

If there is no favicon... There'll still be a request, it'll just 404.

Every modern browser I know of automatically tries to fetch favicon.ico.

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).

[1]: http://stackoverflow.com/a/13416784/149428

On the other hand you only need 2 if you use css image sprites.

Wouldn't this entirely depend on the web browser behavior?

If I'm using lynx, its 1... 1 request.

Am I allowed to Base64 encode the image into the HTML document?