Omitting one feature might not but things add up. Compare HTTP parsing in nginx with this one and you'll notice how much more rigor nginx is about it. Parsing transfer-encoding by itself is costly for example, and nginx does it whether you ask for it or not because it has to populate the structure after all.

Just because features are not used doesn't mean they don't have a cost. Features drives you to make design choices that can affect the overall performance otherwise the feature cannot be implemented. Adding more code to your program might trigger a different code layout which can affect memory cache, and branch prediction.

It's not fair to blindly compare webserver performances without knowing the bottlenecks of each and how the faster webserver overcame those bottlenecks.

It's perfectly fair because those using h2o won't be using any of those features (because they can't). So the fact that nginx provides these unwanted features is irrelevant.

And if you needed those features, then you wouldn't care if h2o is faster or not.

It's not fair because you are not comparing apples to apples. I can write a poll loop that accepts and sends back http responses and call it a webserver.

h2o doesn't even use sendfile(2) which means file data is read and copied to the userland just to be copied back to the kernel to send it to the socket buffer. Turn this on in nginx and you'll see a significant performance improvement.

nginx can be tuned a lot to improve performance and the author didn't bother doing that.