11–20 of 77 posts
"I removed the Disqus comments" Wouldn't that by itself be enough to account for the download time differences?
doesn't disqus start replacing a specific div on a page ready event? If so, disqus loading is 'postponed' to after page loading? Or is it taken into account?
I have Disqus on my Jekyll/Octopress blog and still get millisecond loads.
Earlier quoted context omitted.
doesn't disqus start replacing a specific div on a page ready event? If so, disqus loading is 'postponed' to after page loading? Or is it taken into account?
Disqus replaces the div on page load, then loads the comments asynchronously. I have Disqus on my Jekyll/Octopress blog and still get millisecond loads.
Still, Disqus has basically a no/low-impact
You can put the solutions in the dedicated thread on the site though if you want to share :)
It seems that people on hn just fell in love with go. So many new articles lately. It's like the node.js fever all over again.
Additionally it is funny to see the usual comparisons of young developers discovering execution and compilation speeds already possible in 16 bit systems.
It seems that people on hn just fell in love with go. So many new articles lately. It's like the node.js fever all over again.
OT but please don't put the solutions for Project Euler problems on GitHub, it is directly against the rules ( http://projecteuler.net/about , section "I learned so much solving problem XXX so is it okay to publish my solution elsewhere?"). You can put the solutions in the dedicated thread on the site though if you want to share :)
Seriously the web is big, github is big, Euler is pretty big. Overlap is unavoidable. The [thing,] I'd think would be to ask for no direct linkages. "Go ahead, share your prime factor code, but for goodness sake [do] not document it as a 'Euler Problem.'"
While rewriting things in different language is fun (and fun is a great reason to do stuff), the speed of delivering what is ostensibly static content is a solved problem. This was completely unnecessary. Bake the blog post into static HTML and tune up Nginx to shove it down the wires as fast as possible. Stick it on an CDN somewhere if it's important. Then move on to a problem that doesn't already have an optimal so…
While rewriting things in different language is fun (and fun is a great reason to do stuff), the speed of delivering what is ostensibly static content is a solved problem. This was completely unnecessary. Bake the blog post into static HTML and tune up Nginx to shove it down the wires as fast as possible. Stick it on an CDN somewhere if it's important. Then move on to a problem that doesn't already have an optimal so…
I serve my homepage/blog off a small Sinatra (Ruby) app, and while that's not slow, mostly because it caches every single page in memory permanently (my written content grows much slower in size than available memory on dirty cheap servers) just because it's simple to do and makes my testing easy (it does stat to check for modifications), there's pretty much no excuse not to have a CDN or a fast server like Nginx with caching turned on in front of app servers these days, which makes the backend performance pretty much irrelevant for cases where you don't have content that needs to be dynamically generated for a huge percentage of requests.
How did you achieve a 16 second response time for your blog ? What the heck were you doing?