5 ms·

The paper states that although data use is reduced by 58% on average, the page load time is increased by 6%. Smaller pages are typically slower to load though F

by tyho 11y ago

The paper states that although data use is reduced by 58% on average, the page load time is increased by 6%. Smaller pages are typically slower to load though Flywheel however large pages actually load faster. They do lots of interesting things beyond gzip. They convert images to WebP and scale the resolution of the image based upon the resolution of the host device. They also minify CSS and HTML. What I noticed which I thought was quite cool was they add ETag headers to improve the client's ability to cache resources. They rewrite the response headers to lower case to increase the effectiveness of compression and of course everything is served over SPDY (except in special cases where that fails)

AceJohnny2 11y ago
> Smaller pages are typically slower to load though Flywheel however large pages actually load faster. I was assuming that in this post-Web 2.0 internet, most webpages were heavy (like >1MB), but if I read Figure 3 from the paper correctly, I see that actually about 90% of webpages are <= 500kb. Hm, considering metered data for many (most?) mobile plans, it makes sense to save data for the user, but my initial assumption was that this would make things faster for most people turns out wrong, as demonstrated by the median (not average!) load time increasing by 6%, as you point out.
- GeneralMayhem 11y ago
  >median (not average!) Median is a type of average, and in this case is by far the most important one.
d0vs 11y ago
So basically the PageSpeed optimizations?
- mdwelsh 11y ago
  I'm the tech lead for the Flywheel proxy. The original version of Flywheel actually started with PageSpeed (with a bunch of customizations to focus on compression). You can indeed emulate Flywheel's optimizations with the appropriate configuration options for PageSpeed. We ended up rewriting Flywheel (in Go) in part because we didn't need all of the complexity that PageSpeed provides, but also to streamline the process of running the service in Google's datacenters, rather than in an Apache or NGINX environment.

by tyho 11y ago

AceJohnny2 11y ago

> Smaller pages are typically slower to load though Flywheel however large pages actually load faster. I was assuming that in this post-Web 2.0 internet, most webpages were heavy (like >1MB), but if I read Figure 3 from the paper correctly, I see that actually about 90% of webpages are <= 500kb. Hm, considering metered data for many (most?) mobile plans, it makes sense to save data for the user, but my initial assumption was that this would make things faster for most people turns out wrong, as demonstrated by the median (not average!) load time increasing by 6%, as you point out.

GeneralMayhem 11y ago
>median (not average!) Median is a type of average, and in this case is by far the most important one.

d0vs 11y ago

So basically the PageSpeed optimizations?

mdwelsh 11y ago
I'm the tech lead for the Flywheel proxy. The original version of Flywheel actually started with PageSpeed (with a bunch of customizations to focus on compression). You can indeed emulate Flywheel's optimizations with the appropriate configuration options for PageSpeed. We ended up rewriting Flywheel (in Go) in part because we didn't need all of the complexity that PageSpeed provides, but also to streamline the process of running the service in Google's datacenters, rather than in an Apache or NGINX environment.