It would be valuable to know what file a browser has found to read to render the home page of domain. I know the browser goes to something like google.com and then starts to look for default file names/types such as index.html then perhaps index.htm and so on through a list of about a dozen other files. I'm curious what file my browser has actually began to render (right clicking in the browser window and clicking Save As doesn't give the file name), and then secondly, I wonder if a site would begin to render faster if the file name present on the domain (e.g. index.php) was one of the initial file attempts the browser looked for vs. something more atypical (eg. placeholder.html). 
How can I see what filename my browser is reading when it's on a site?
browsers;homepage;filenames
Your browsers doesn't load any file, it requests a resource which the server then provides at his discretion (lengthy elaboration below). If you type google.com into your browsers toolbar, the browser wil first append a protocol, either http:// or https.Then browser will look up the IP address belonging to google.com, which is 172.217.19.206. Your browser will then establish a socket with that server on the proper port (80 for http, 443 for https). Your browser will then send the following request to the server:GET / HTTP/1.1Host: google.comThe web server will then decide what to do. This can involve a lot of steps. A web server usually has something called a document root for any domain he serves. Files that the web server is allowed to serve the user usually reside inside this document root. For example, the document root for google.com might reside at /var/www/domains/google.com/htdocs/.Now, when you request a resource the web server first inspects the resource, and then takes proper action. For example, if the resource ends wih .php, the web server might decide not to serve anything himself, but instead invokes the PHP interpreter, and lets the PHP interpreter execute the proper PHP-file for the requested resource, and then serves the user the output.Take for example this request:GET /article.php?id=123456 HTTP/1.1Host: news.example.orgIn this case, the web server on news.example.org is tasked to serve the resource /article.php?id=123456. What likely happens is that this web server will start the PHP interpreter. fetch the article.php file from the document root, feed it into the PHP interpreter and wait for the output. It will then send the output bck to the browser that requested it. In this case, this would likely be a site from a blog with certain content loaded from a database (the contents of the article stored with the id 12345).But other things can happen, too.Lets get back to the original example:GET / HTTP/1.1Host: google.comWhat with any stanadard web server (Apache, Lighttpd, etc.) happens, is more or less the following:Look for a file named index.html (in the document root) and serve itIf that doesn't exist, look for a file index.htm and serve itIf that doesn't exist, look for a file index.php and start the PHP interpreter, serve the outputIf that doesn't exist, serve a 404 NOT FOUND errorThe precedence of the extension is usually configurable on the side of the web server. The server might not serve any index.xxx file at all. For example, if you have a node.js server running, then the web server would task the node.js server to provide the resource /, which might just be anything the JS-App that is runnng on node decides it to be.tl:dr; The browser doesn't look up a file. The browser requests a resource, the web server then handles the request and serves the content approrpiate for  the requested resource, which might be a file, but might also be the output of a 3rd-party program.As far as speed is concerned, this is dependent on the web server. But if you want your web server to always serve the asjkdjhfz9874jykdfndsk.html file when / is requested, you would usually configure the web server to look for such a file first, making it as fast as any other configuration.Disclaimer This is not a full decsription how any web server works, nor tailored specific to one. Most web servers work similar, but especially sites like google.com will likely run some custom things that are tailored specifically to their needs.Your browser will usually offer tools to inspect network activity. Using Chrome, you can open the Dev tools and inspect the headers. this is what my browser send to SE to let me edit this answer:GET /posts/93567/edit HTTP/1.1Host: webmasters.stackexchange.comThere are a few more that tell the server about caching, what language I am expecting, what browser I am using and where I'm coming from, but those aren#t interesting here. The point is, my browser requests the resource /posts/93567/edit. My browser will never have any idea about what file the web server serves. SE runs on ASP.NET MVC 5, which means that the web server (in SEs case, an IIS) will likely load some proper .asp file (that can be located anywhere), and lets the runtime evaluate it for the parameter postId=93567. The actual file or inner workings are never exposed to the browser, because the browser doesn't need to know (and because it is safer to hide that information for the one running the server).The view will also show you any other resources (CSS files, JS files, images etc.) that your browser requests to correctly render the site. But with them, you will only learn about the resource, not wether or not those are actually files in the file system.