Another optimization in the same vein: make sure the first KB contains the <meta charset> element, to avoid false-starts in the HTML parser. In fact, it's actually specified as an _error_ in the spec to have it come after 1KB!
It's mentioned in passing on the Lighthouse docs for the charset audit[1], but here's a great breakdown by hsivonen[2].
Of course, in the headers is even better. Point is, try not to have too much cruft before the charset.
English is my second language, and the comma separating that particle from the rest of the sentence makes it pretty explicit even for me that it is talking about the platform, at the same semantic level as “powerful”, “extensive” and “to serve your sites […]”.
Yes, but the incongruousness of telling me what language something is written in in its sales one-liner makes me think it must be pitching itself as "especially for apps written in Go", because who thinks I am going to pick a tool because it is written in Go? "Try ElasticSearch, written in Java!"
I avoid new server software written in languages with too many footguns such as c or php. Nginx gets a grandfather exception, but I'm not sure I would have extended one to caddy.
> easy to configure, relatively flexible, sane defaults
Compared to what? You think nginx is not easy to configure or has insane defaults somehow? Really baffled why people come out of the wood work to pile on beautifully architectured designs in favor of some random project they happen to like or just because it's written in a language they have a special affinity for like Go or something.
Have you used Caddy for reverse proxying compared to nginx? It's infinitely easier. Two lines per site, https built in, dynamic upstreams are handled by default, HTTP 2 enabled (maybe nginx does HTTP 2 by default,; not sure).
Easier in what sense? If you find the most esoteric feature and then claim it's easier for that purpose, that doesn't count! If you're going to claim it's easier to configure than nginx you have to make a fair comparison by comparing not the features that you care about, but instead the features that define the system as a whole.
I have a feeling you're think we're attacking nginx. I can't speak for the other poster, but I have huge respect for nginx. It's a great piece of software and it's what I'd reach for in production.
I'm not sure that Caddy is a good choice for production, but for my hobby work it is just so much easier to use.
I looked into nginx as a replacement for Apache a few years ago and gave up because of the weird dichotomy between open-source nginx and commercial nginx. There seemed to be a lot of FUD about the OS version coming from the commercial people so I moved on.
With the announcement a couple of days ago that the commercial nginx folks are embracing OS again I might take another look.
The paid version (nginx plus) has a few additional features that you often end up needing/wanting (the dashboard for example, for ops users) in enterprise environments.
For what its worth, I switched from nginx to Caddy years ago and haven't looked back - Caddy's built in support for LetsEncrypt and zero configuration for the most common reverse proxy scenarios is just too compelling to ignore now - the speed and ease with which one can throw up an SSL front end with valid letsencrypt cert is amazing.
It's mentioned in passing on the Lighthouse docs for the charset audit[1], but here's a great breakdown by hsivonen[2].
Of course, in the headers is even better. Point is, try not to have too much cruft before the charset.
[1] https://web.dev/charset/
[2] https://github.com/GoogleChrome/lighthouse/issues/10023#issu...