Hacker News Reader

Comment by largehotcoffee | Hacker News Reader

A quick look shows that you could minify the Javascript quite a bit more (which is relatively easy, and would save a lot more than 50 bytes). You might also look at inlining all of the Javascript into the HTML directly (this is what Google does), which saves the extra HTTP requests. You could also do this with some of the persistent images on the page (logo) and inline them with base64 (but I don't think it actually helps with the page size).

Finally, instead of using the browser extensions (which are helpful), get actual PageSpeed installed on the servers!

Apache: https://developers.google.com/speed/pagespeed/module nginx: https://github.com/pagespeed/ngx_pagespeed

Regardless, awesome stuff. Big fan. Much love.

View on HN

Thanks for pointing that out. We minify production JS using Closure Compiler but sometimes that leaves room for improvement.

There's definitely a tradeoff between inlining JS and small images, but I think in our case it makes more sense to leave them external to leverage browser (and since we use a CDN for static content -- edge) caching.

I believe I tried to get ngx_pagespeed up and running when it was announced, but couldn't get it to compile from source. Sometimes (read: often) it sucks to be a FreeBSD user.

It is the second time in this discussion that you mention the downsides of using FreeBSD, and you present it as an historical choice. Do you have upsides as well? What were the criteria that made you pick, 10 years ago, FreeBSD over another OS?

I've found that uglifyjs does about as good a job as Closure Compiler, but waaay faster. Could be a nice speed up in deploy times for you.

closure kicks uglify for size when compiling with advanced optimisations.

I found that the advanced optimisations broke our Javascript when I compared the two a couple of years back. We weren't interested in rewriting our Javascript to make it compatible with the Closure.

The thing that will break your code is this type of notation this['function'] since the compiler can have no idea what renaming should apply. There are aspects of the library that lets you expose public apis.

I can really recommend the compiler in AO mode, the type saving is insane (75% reduction in file size) and type checking is sweet

    which saves the extra HTTP requests

The reason google does it is due to them wanting a fast single page load.

4chan reloads the the page on each click meaning you save a shitload of bandwidth by not having to send the scripts and css each time the page loads.

You're absolutely right, I was just sharing some other options. Given the way 4chan is currently built inlining all of the Javascript would not be beneficial over keeping it external and allowing the browser to cache it.

Wouldn't inlining the js mean that it's downloaded for every page request instead of being downloaded once and cached?

Yes. Along with base64ing the logo. Better to serve those with some nice HTTP cache headers.

Each page of the site isn't all that different from the rest. They could just load the page once and update the page content with a JS AJAX call and DOM manipulation, honestly. You wouldn't even need to send full URLs for the images that way, just the unique part of the URL such that JS could reconstruct it from a constant prefix.

We actually do this with reply loading already, but not by default. We have a read-only JSON API and use that to append new replies when you're browsing in a thread (click [Update] or [x Auto] at the top/bottom of a thread). We also have a de-pagination feature that grabs all of the OPs from a board and let's you scroll through the indexes as one giant page.

Reply on news.ycombinator.com