5 ms·

"I am now loading less static assets. I removed the Disqus comments and the many many lines of CSS from the old site and replaced it with only a couple of lines

by jbail 13y ago

"I am now loading less static assets. I removed the Disqus comments and the many many lines of CSS from the old site and replaced it with only a couple of lines of CSS alongside a CDN-hosted copy of Twitter Bootstrap. Finally, the Go site is deployed to a free instance of Heroku and the MongoDB hosted on a developer version of Mongolab, while the old Django site was hosted on a Webfaction shared server." So...the Python/Django to Go/Revel comparison is basically worthless then? These are huge changes that completely invalidate any speed improvement the author is trying to prove are a result of using Go. A lot of upvotes for an article with an obviously flawed conclusion.

asdfologist 13y ago
Did you read the next sentence? "All these things influence the validity of a direct speed comparison between the two versions, but the speed improvement is nevertheless too overwhelming to attribute only to these small changes. And in fact, many of these changes might even have negatively impacted the speed of the new version in exchange for saving on the monthly bills."
- ebbv 13y ago
  That assertion isn't backed up with data, though. Without showing how many seconds were spent loading Disqus, we don't know how much of the load time improvement was based on eliminating Disqus vs. the switch to Go. Based on experience I'm guessing the lion's share of the gain is due to eliminating Disqus.
  - bdcravens 13y ago
    Isn't Disqus loaded client-side? If so, it's not comparing to Go as much as rendering comments server-side, which you'd see performance increases with PHP or Rails as well.
ignostic 13y ago
And the very next sentence: >"All these things influence the validity of a direct speed comparison between the two versions" I hope the author wasn't trying to say, "Go is better always forever." I read it more as, "hey I rebuilt my site in Go, and it's fast." Go has potential - I'll be excited to see what people come up with.
bhauer 13y ago
I am left wondering: Why not just measure/compare the response time of the single request that fetches the (presumably) HTML response, and leave all of the ancillary asset delivery and script execution as an aside? If this is about Go versus Python, all I care about is the portion where those are actually involved. And it would be easy to see in the network panel of the developer tools window in Chrome or Firefox. Of course, the hosting environment also changed, so... there's that still.
waivej 13y ago
I recently benchmarked an uncached remote ASP site versus a local Node.js copy that returned identical HTML. Of course, Node was 100x as fast. (1ms vs 200ms) However, in the browser, they felt like the same site. The 199ms head start resulted in only 50-75ms difference in the browser. Anyway, it turned our focus from backend work to CSS and image improvements.
- wldlyinaccurate 13y ago
  I wish more web developers would come to this conclusion. It's so frustrating to see people trying to save 50ms by optimising slow SQL queries or fixing slow code paths. Meanwhile the user is waiting over 5 seconds to load a page with a bloated DOM, inefficient CSS, synchronous JavaScript, etc. If your back-end is slow, just cache it and forget about it. Front-end is almost always the bottleneck (the exceptions to this rule being near-real-time dynamic sites like New Relic or GoSquared).

by jbail 13y ago

asdfologist 13y ago

Did you read the next sentence? "All these things influence the validity of a direct speed comparison between the two versions, but the speed improvement is nevertheless too overwhelming to attribute only to these small changes. And in fact, many of these changes might even have negatively impacted the speed of the new version in exchange for saving on the monthly bills."

ebbv 13y ago
That assertion isn't backed up with data, though. Without showing how many seconds were spent loading Disqus, we don't know how much of the load time improvement was based on eliminating Disqus vs. the switch to Go. Based on experience I'm guessing the lion's share of the gain is due to eliminating Disqus.
- bdcravens 13y ago
  Isn't Disqus loaded client-side? If so, it's not comparing to Go as much as rendering comments server-side, which you'd see performance increases with PHP or Rails as well.

ignostic 13y ago

And the very next sentence: >"All these things influence the validity of a direct speed comparison between the two versions" I hope the author wasn't trying to say, "Go is better always forever." I read it more as, "hey I rebuilt my site in Go, and it's fast." Go has potential - I'll be excited to see what people come up with.

bhauer 13y ago

I am left wondering: Why not just measure/compare the response time of the single request that fetches the (presumably) HTML response, and leave all of the ancillary asset delivery and script execution as an aside? If this is about Go versus Python, all I care about is the portion where those are actually involved. And it would be easy to see in the network panel of the developer tools window in Chrome or Firefox. Of course, the hosting environment also changed, so... there's that still.

waivej 13y ago

I recently benchmarked an uncached remote ASP site versus a local Node.js copy that returned identical HTML. Of course, Node was 100x as fast. (1ms vs 200ms) However, in the browser, they felt like the same site. The 199ms head start resulted in only 50-75ms difference in the browser. Anyway, it turned our focus from backend work to CSS and image improvements.

wldlyinaccurate 13y ago
I wish more web developers would come to this conclusion. It's so frustrating to see people trying to save 50ms by optimising slow SQL queries or fixing slow code paths. Meanwhile the user is waiting over 5 seconds to load a page with a bloated DOM, inefficient CSS, synchronous JavaScript, etc. If your back-end is slow, just cache it and forget about it. Front-end is almost always the bottleneck (the exceptions to this rule being near-real-time dynamic sites like New Relic or GoSquared).