Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How to Interpret Site Performance Tests

fly.io

Post reply on HN
Print view View original

11–15 of 15 posts

Re: How to Interpret Site Performance Tests

#11

Post by matahwoosh »

d0ugie wrote: post #9

Amazing how many e-commerce sites there are out there with time to first byte in excess of 3s, DOM loads over five seconds, as if they have no idea they are throwing away sales and killing their SERP ranks. And the fixes quite often don't require money or that much skill, just a little help from something like Varnish in many cases. Is the only good way for me to use QUIC with NGINX (or any server that can deliver mo…

There's definitely some truth to how (at least some of) e-commerce sites could be easily sped up. Part of the problem is that you have a combination of legacy stack, organizational inertia, lack of know-how and resource outsourcing (so 3rd party vendors owns parts of the stack).

And specifically, wrt caching and varnish, as soon as you put something in your cart and you're cookie'd pages you visit are not cacheable.

Re: How to Interpret Site Performance Tests

#12

Post by matahwoosh »

d0ugie wrote: post #9

Amazing how many e-commerce sites there are out there with time to first byte in excess of 3s, DOM loads over five seconds, as if they have no idea they are throwing away sales and killing their SERP ranks. And the fixes quite often don't require money or that much skill, just a little help from something like Varnish in many cases. Is the only good way for me to use QUIC with NGINX (or any server that can deliver mo…

Also, a note on QUIC. Seems like the spec is a draft and is not going anywhere right now, but Google has made big progress with TCP BBR control-flow algo, and there's also TCP Fast Open and TLS 1.3 0-RTT to look forward to.

Moving more delivery (not just static content) to edges + using HTTP/2+Push should help a lot with perf, too.

Re: How to Interpret Site Performance Tests

#13

Post by matahwoosh »

ianamartin wrote: post #3

One thing not explicitly mentioned here is what happens to your performance profile under load. You can have a well-designed app with solid, maintainable code, but your overall stack isn’t set up to handle simultaneous users. Whether it’s node, ruby, python, or php, you still have to consider things like your web server, reverse proxy, load balancer, and database configurations. When I’m building things that are goin…

I agree with you that the earlier you can catch those performance issues, the better. It's just like with catching bugs early in your development cycle. You could even argue that poor perf is a bug!

The more you know about the performance characteristics of your stack, the better, but given how many 3rd party services you might be using in production it might be close to impossible to predict that. Either way, you should be constantly monitoring the performance of your applications (backends, DBs, browser timings, RUM, cross-stack traces etc.) .

Looking forward to your Show HN on monitoring :)

Re: How to Interpret Site Performance Tests

#14

Post by matahwoosh »

ahmetkun wrote: post #8

Which is more beneficial in today's web: Serving static contents from a cookieless domain but two dns lookups vs. all contents from same domain, but one dns lookup?

I think there's no straightforward answer to this. E.g. why would you have 2 DNS look-ups with cookieless domain? I imagine that means cdn.mydomain.com and mydomain.com?

If you're using HTTP/2, then one domain is better, because you can use the same persistent connection to multiplex your traffic. Well, technically, if you use the same IP and SSL cert then you can HTTP/2 Push the contents to the client (doesn't have to be the same domain).

However if your web server is slow or if the distance between the client and your web server is significant then you're likely not going to benefit from the performance gains of using one connection, because of the network propagation delay (vs low latency POPs from major CDNs).

Lastly, your static assets don't have to be on a cookieless domains, you can just strip the cookies and cache the content - that's what many varnish instances do ;)

Post reply on HN