This seems like it'd be particularly helpful for dealing with the incredibly excessive CSS layers in Google websites like Google+ (which locks up my browser for five seconds when it loads). But I'd be pretty iffy giving my login details through a proxy like this.
We don't store anything you type into forms, and don't store any cookies any longer than the browsing session is alive (currently expires after 5min of inactivity). But you're right of course, as a user you have no way of verifying this. The main scenario I was envisioning here is things like news sites, which often go overboard with complex scripts, CSS, images/videos/flash, ads, etc, to the point where a simple news article is difficult or impossible to read - especially on an older device or on a slow 3G connection.
I see the actual speed benefits immediately, I tested it with a public G+ post URL, and it loaded much faster than my laptop can load a G+ page normally, and without causing my browser to freeze up.
Out of curiosity, what's the monetization or business plan with this?
Thanks! Monetization is not fully thought out yet but I'm envisioning a freemium model down the line. Basically, either start charging after a certain usage threshold (e.g. an hour of free browsing per day), or charge for extra features like server-side ad-block, ability to pick the country in which the server's IP is located, HTTPS access (even though HTTPS is currently free), etc.
The biggest concern, particularly down the road, is assuring people you're above board on security. When I mentioned it on G+, the first suggestion was that you guys could inject ads and such, which obviously would be a huge problem.
But generally if there's a solid paid model, a company can be pretty free and clear of those problems.
The other thing you would want to consider is Firefox and Chrome plugins where you could set specific sites to open via your protocol. Maybe Engadget doesn't work well on my computer for whatever reason, so I tell the extension to open all Engadget URLs through your service, or something like that.
Agree on the security aspect, and injecting ads would be horrible, I definitely think there are better monetization models here. Plugins are an interesting idea, will give it some thought. Though for now, I'm thinking in a different direction... I think FasterBadger is mainly applicable to mobile (since complex pages would be much more overwhelming to phones than desktop machines), and plugins are less of a thing there. However, a native app that speaks the FasterBadger protocol (essentially an alternative browser app) could be interesting.
My first thought upon seeing this is regarding a way to build this into a web proxy, & let a local server do the work while clients only have to be configured to use the proxy. Dunno if its feasible, not knowing how it works, but it seems promising.
Interesting idea. Unfortunately FasterBadger is far from being a universal browser now, there are still many sites that it won't support or won't support well (anything that relies on more than just basic click and keyboard input events), so the degree of integration you're talking about probably isn't appropriate yet... but perhaps will be in the future.
There is another option inside the browser by using WebKit.js (https://trevorlinton.github.io/) for the rendering and send the page encrypted to the browser with XHR (or with another method).
Thanks! WebKit.js could be interesting down the line, thanks for pointing it out, though I wonder about performance and standards compliance. There's also the stability issue - the page says it's "experimental/unstable/not yet alpha". FasterBadger is based on the much more stable PhantomJS, and still plenty of gnarly bugs are coming out.
This is an interesting idea. Is there an intended use case? The page says to "speed up browsing on many websites by rendering them in the cloud", but as far as I can tell this also means we have to wait for the entire page to render before we are sent the png's. Along with the increased latency by going through FasterBadger instead of through the CDN's.
Or is it for sites where most of the times is spend on the rendering client side?
It actually starts rendering even before the entire page is ready (and fixes up the page later; well, in the current version it just re-renders the page later). For some sites (news sites tend to be particularly bad here), rendering on the client takes significant time, especially with older phones - because of complex scripts, styles, many re-layouts/reflows, ads/trackers (which bring their own scripts/styles), and so on. Additionally, there's the issue of the number and size of network requests, which can be a problem over slow 3G connections. Of course, I could be wrong in these assumptions, and it could be the case that with improved networks, improved hardware and better-optimized sites none of this will be an issue. So FasterBadger is an experiment - will server-side rendering be enough of an improvement for people to change browsing habits? What about people with slower phones and slower networks, e.g. in developing countries? We're definitely finding sites today that e.g. don't display any content for a whole 30-60sec on an iPhone4 and display in mere seconds via FasterBadger, but of course not every site will be sped up.
16 comments
[ 4.7 ms ] story [ 523 ms ] threadOut of curiosity, what's the monetization or business plan with this?
But generally if there's a solid paid model, a company can be pretty free and clear of those problems.
The other thing you would want to consider is Firefox and Chrome plugins where you could set specific sites to open via your protocol. Maybe Engadget doesn't work well on my computer for whatever reason, so I tell the extension to open all Engadget URLs through your service, or something like that.
There is another option inside the browser by using WebKit.js (https://trevorlinton.github.io/) for the rendering and send the page encrypted to the browser with XHR (or with another method).
Or is it for sites where most of the times is spend on the rendering client side?