Not to mention that pipelining already exists to avoid dropping the connection if its known that several pieces of data are required.
From the client side a single initial connection to pull the base code then the browser makes multiple requests simultaneously for the resources required to render the page triggering creation of a bunch of TCP flows - a nicely optimised page where the initial request allows parallel requests for everything else, no dependencies on any of the secondary resources to load others. Zoom zoom.
From the server side it sends the FIN when it knows its work is done. It knows its work is done when its HTTP daemon tells it its work is done. If the browser is parsing what it receives in a timely fashion and, as you said, making a series of requests via that TCP connection, pipelining, the server's HTTP daemon will service them.
A well programmed browser dedicated to being as fast as possible does a combination of both - has a maximum simultaneous connection limit to a server it's permitted to try and open and pipelines requests along all of them.
Produces efficiency gains all around - it's fine for the TCP connections to be open as long as they are doing something. Servers waiting for timers to run down aren't spending their time wisely.
That is something I have a lot of experience with professionally but is potentially outside of this thread.
