Just spotted this recently released article. An interesting read. Thought it might be worth sharing.
My opinion of the article is neutral with a mostly negative lean.
I don’t think it’s particularly interesting. It is not technical. It is lazily researched. It doesn’t really say much that isn’t already well-known or easily guessable. I also think its claims are dubious and its overal conclusion isn’t helpful.
Caddy provides the following directives:
file_server: implements a static file server
php_fastcgi: proxies requests to a PHP FastCGI
reverse_proxy: directs incoming traffic to one or more backends with load balancing, health checks, and automatic retries
That’s like 1/10 of the Caddyfile directives, but OK.
In terms of performance, Caddy has been shown to be competitive with Apache but behind Nginx both in terms of requests handled per second and stability under load.
Using 17-month-old benchmarks, which I still have qualms with as I’ve run Caddy to be faster than nginx. This was 6 years ago, and frankly it has only improved since then, but benchmarking web servers like this is useless for general consumption.
(And Caddy is basically as performant as any other Go server, which is not slow.)
If Nginx is being used for performance optimization, it may not be possible to replace it with Caddy without observing some degradation in performance.
I could say the inverse too. And if Caddy’s 50K+ or 100K+ req/sec aren’t fast enough for you, you’ve got bigger problems. Your bottleneck is not your web server, and I’ll argue that web server performance doesn’t matter these days for most sites. It’s an over-hyped useless metric.
Another possible downside to Caddy is that it currently has a small market share, possibly limiting resources for education and troubleshooting:
Sure, we all know that nginx is used on most sites and that Caddy is not. These stats are probably derived from scanning Server headers, which many Caddy users strip for some unknown reason, or at least a reason I don’t fully understand.
In this article, we discussed some of the key traits of Caddy, Apache, and Nginx to help you choose the web server that best suits your project’s needs.
The article didn’t talk about needs, only performance and configuration, and not nearly technically or rigorously enough to be useful. Sloppy at best.
If your primary concern is performance, or you plan to serve a large amount of static content, Nginx is likely your best option.
Should read: “If your primary concern is performance, you wouldn’t be reading this article, because you’d be busy profiling and tuning your bottlenecks, not racing web servers. If you plan to serve a large amount of static content on sites that scale your HTTPS gracefully and reliably, Caddy is your only option.”
While Caddy is easy to configure and performant for most use cases, if you need flexibility and customization, Apache is your best bet.
This is bull–, ahem I mean, this is unsubstantiated.
Keep in mind that you can also combine any two web servers for a great result. For example, you can serve static files with Nginx and process dynamic requests with Apache or Caddy. Thanks for reading, and happy coding!
Citation needed. This is a bit dismissive, isn’t it? You should not combine two web servers for a “great result” unless you absolutely need to. The example here doesn’t make any sense. More moving parts will only complicate and slow down your setup, for instance:
I think the article is just marketing fluff to gain keywords and high results in the SERPs.
I thought this might hit a nerve. I totally agree with your assessment btw. I looked at this article in a slightly different manner. I think the positive to take away is that Caddy has been noticed. Someone has decided to include Caddy in a (loose) comparison with the two dominant players rather than choose another webserver such as IIS or LightSpeed for the comparison, which, according to the stats, have a higher market share than Caddy. Based on this article, Caddy appears to be the preferred webserver to assess Nginx and Apache against.
That is true. It is refreshing to see Caddy considered along the likes of nginx and Apache, “industry giants” (especially considering its apparent relative market share). So I do appreciate that.
Apache has better error output (that I know of), especially with trace logging enabled. This is something that might have helped my unsolved http3 issues. For example I’ve debugged issues with tls sessions using trace debug mode and ultimately found several bugs that was reported and fixed.
The article doesn’t really say much with very little to back things up. Though I found it odd that they imply that it’s only Caddy that provides TLS 1.3.
But it’s good to see Caddy mentioned.