6 ms·

Torbit – Making Websites Faster

15 points by johns 16y ago

Mithrandir 16y ago
So it's SaaS?
- whimsy 16y ago
  Yeah. It looks like it's basically an almost-no-setup proxy kind of thing.
  - joshfraser 16y ago
    Exactly
bmelton 16y ago
I can't tell how similar this is to CloudFlare, but it looks close. That said, CloudFlare actually increased latency by a non-trivial amount, which caused me to abandon it. It may be better now, or it may have worked better on much larger sites, but my 256M slice & Django blog was faster without it.
- whimsy 16y ago
  damoncloudflare replied to you elsewhere on this comment page.
- joshfraser 16y ago
  The big difference is Torbit's focus on the other front end optimizations besides moving resources to a CDN. We compress CSS & JavaScript. Reduce HTTP requests. Optimize images. Preload content. And lots more. CloudFlare as I understand are focused on being a really good and easy to use CDN. And yes, the cloud approach means that we add about 200-300ms to every non-cacheable request. We think it's a decent trade-off since we usually shave off 10 times that when all our optimizations are applied.
jules 16y ago
I think Google has a similar tool freely available, although I can't find it right now. Does anybody know?
- requinot59 16y ago
  mod_pagespeed?
- joshfraser 16y ago
  They released an open source apache module called mod_pagespeed. We actually set up a proxy for it so you can see what it would do to your site without having to install anything: http://torbit.com/proxy http://torbit.com/proxy One reason people may prefer a cloud solution is there is no other infrastructure to set up. It turns out mod_pagespeed is both CPU and cache intensive which means rolling this out on your servers requires beefing up your server infrastructure. We may end up using their technology & contributing to the project at some point, but right now it's very alpha and breaks a lot of sites (including Google's own!). They're also missing most of the browser-specific optimizations that we're doing, specifically around mobile.
wccrawford 16y ago
" but many of these are still not done because they’re annoying and tedious to do and developers are often focused on other things. " To me, that situation always meant I'd find (or code) a tool to make that happen automatically. Having the right tools for the job always means things go better, both for the developer and the client.
damoncloudflare 16y ago
Hi bmelton, Looks like you were active around the TC Disrupt time, which was very busy for us (we've added two datacenters since then). We generally make websites about 30% faster on average.
- jrosoff 16y ago
  Curious how you measure the improvement you make to your customer sites. Can you explain the methodology?
- nphase 16y ago
  You know that you can reply directly to his comment, right?
- bmelton 16y ago
  That's exactly right, I was indeed. I did give it a couple of weeks, but I had a knee-jerk reaction at a point when I was dealing with a customer onsite. The gig was to migrate some of his company's products to the web, and of course, his main concern was on the speed -- he didn't believe the web could be as fast as a native client. While there's merit to that on its own, my attempts to show otherwise were thwarted by a really slow CloudFlare CDN, at the time, so I kiboshed it. I blogged about it at the time, and hoped that it was just due to what I'm sure was unexpected expansion in the light of the Disrupt coverage, but truthfully, I don't currently have any products large enough to benefit from it. It seemed like a cool service, and having recently gone the other way (implemented Amazon's CloudFront / caching / yadda yadda), I will attest that CloudFlare's implementation was far easier and more convenient. I'll try to check you guys out again soon. Thanks for the comment!

15 points by johns 16y ago

Mithrandir 16y ago

So it's SaaS?

whimsy 16y ago
Yeah. It looks like it's basically an almost-no-setup proxy kind of thing.
- joshfraser 16y ago
  Exactly

bmelton 16y ago

I can't tell how similar this is to CloudFlare, but it looks close. That said, CloudFlare actually increased latency by a non-trivial amount, which caused me to abandon it. It may be better now, or it may have worked better on much larger sites, but my 256M slice & Django blog was faster without it.

whimsy 16y ago
damoncloudflare replied to you elsewhere on this comment page.
joshfraser 16y ago
The big difference is Torbit's focus on the other front end optimizations besides moving resources to a CDN. We compress CSS & JavaScript. Reduce HTTP requests. Optimize images. Preload content. And lots more. CloudFlare as I understand are focused on being a really good and easy to use CDN. And yes, the cloud approach means that we add about 200-300ms to every non-cacheable request. We think it's a decent trade-off since we usually shave off 10 times that when all our optimizations are applied.

jules 16y ago

I think Google has a similar tool freely available, although I can't find it right now. Does anybody know?

requinot59 16y ago
mod_pagespeed?
joshfraser 16y ago
They released an open source apache module called mod_pagespeed. We actually set up a proxy for it so you can see what it would do to your site without having to install anything: http://torbit.com/proxy http://torbit.com/proxy One reason people may prefer a cloud solution is there is no other infrastructure to set up. It turns out mod_pagespeed is both CPU and cache intensive which means rolling this out on your servers requires beefing up your server infrastructure. We may end up using their technology & contributing to the project at some point, but right now it's very alpha and breaks a lot of sites (including Google's own!). They're also missing most of the browser-specific optimizations that we're doing, specifically around mobile.

wccrawford 16y ago

" but many of these are still not done because they’re annoying and tedious to do and developers are often focused on other things. " To me, that situation always meant I'd find (or code) a tool to make that happen automatically. Having the right tools for the job always means things go better, both for the developer and the client.

damoncloudflare 16y ago

Hi bmelton, Looks like you were active around the TC Disrupt time, which was very busy for us (we've added two datacenters since then). We generally make websites about 30% faster on average.

jrosoff 16y ago
Curious how you measure the improvement you make to your customer sites. Can you explain the methodology?
nphase 16y ago
You know that you can reply directly to his comment, right?
bmelton 16y ago
That's exactly right, I was indeed. I did give it a couple of weeks, but I had a knee-jerk reaction at a point when I was dealing with a customer onsite. The gig was to migrate some of his company's products to the web, and of course, his main concern was on the speed -- he didn't believe the web could be as fast as a native client. While there's merit to that on its own, my attempts to show otherwise were thwarted by a really slow CloudFlare CDN, at the time, so I kiboshed it. I blogged about it at the time, and hoped that it was just due to what I'm sure was unexpected expansion in the light of the Disrupt coverage, but truthfully, I don't currently have any products large enough to benefit from it. It seemed like a cool service, and having recently gone the other way (implemented Amazon's CloudFront / caching / yadda yadda), I will attest that CloudFlare's implementation was far easier and more convenient. I'll try to check you guys out again soon. Thanks for the comment!