Hacker News new | ask | show | jobs
by r00tbeer 973 days ago
I think that URL gets served by the same single binary. Might look like multiple files and connections to you ...
2 comments

Maybe. Seems odd that they'd use a vestigial 'static' directory in the request path, though. I didn't read it because the layout makes it useless on mobile browsers, but I have a feeling they mean that the whole site is coded into one binary like a self-contained ssg rather than the site only requiring one file to work.
The static files are probably a directory embedded into the binary with Go's embed package, and mounted on /static.
But why? Why not serve all needed content inline?
Because that means every page request downloads all the static content. It’s generally nice for people if they only have to download the shared assets once.
The stylesheet is just under 3KB even with no minification or compression. At that size, the cost is negligible, and inlining will consistently be faster to load even than a warm cache of an external stylesheet. In most conditions, you’ve got to get towards 100KB before it even becomes uncertain. Loading from cache tends to be surprisingly slow, vastly slower than most people expect. (Primary source: non-rigorous personal experimentation and observation. But some has been written about how surprisingly slow caches can be, leading to things like some platforms racing a new network request and reading from disk, which is bonkers.)

Seriously, people should try doing a lot more inlining than they do.

I think it depends on how you set your cache? If it’s not configured to re-check with the server it may be much faster.

Then again, for 3KB the overhead of doing a cache check after parsing the HTML for the first time and then rendering it again may already be too much :)

Exactly. Inline is just surprisingly much faster than a lookup by URL, which has to check “do I have this cached? What type (immutable, revalidate, &c. &c.)? Now (if suitable) fetch it from the cache.” before it can get on with actually acting on the resource’s contents.
interesting. i shall consider this :)
I sincerely doubt that the assets on the site in question are large enough to warrant this.
Sometimes browser caching and ease of development is the reason here.