Technically yes, but then on the next page load, that stylesheet / js file / image, whatever external resource is cached. So It doesn’t have to come across the internet again, it just comes right from your local machine. If you embed everything into every page, everything has to be re-downloaded each time. Of course it’s more complicated than this, but that’s a foundation to start going to down the rabbit hole or whatever.
Using external style sheet has many advantages over inline or embedded styles which I won’t rehash here. There’s plenty of info on the web about that. As far as speed difference between pages with linked style sheet and or pages with inline or embedded styles is probably so minuscule that it’s going to be hardly noticeable if at all and only during the the viewing of the first page.
Since client cache stores style sheet upon a visit to first page, viewing of subsequent pages will be quicker and smoother. At this point, the speed is only affected by the latency of browser itself.
That article is about jQuery but the information about caching applies to your case as well. The most interesting part is this:
> When you’re dealing with large assets, a 304 response can save significant amounts of download time. Unfortunately, with a file as small as jQuery, the ceremony necessary to retrieve that 304 response is nearly as time consuming as just downloading the file in the first place.
jQuery is a pretty large file compared to your CSS file (probably), so I think this is what Chris means by it’s more complicated than that. The solution is far future caching, which eliminates the 304 ‘handshake’. The only downside is that you need to rename the file on every update you make, otherwise users who have the cached version won’t see the update. (some people suggest added a query to the CSS url like `global.css?v=1.2`, but it turns out proxies won’t cache that, so `global.v1.2.css` would be better)