Live data from Hacker News

Google Page Speed Online

pagespeed.googlelabs.com

31–40 of 40 posts

Re: Google Page Speed Online

#31

I only got 97/100 for https://grepular.com/ because: 1.) I have 306 Bytes of inline JavaScript 2.) Minifying https://grepular.com/ more than it already is could save 794 Bytes, ie less than 1% of the page size. 3.) They want me to defer javascript until after page load. It's the last thing in the body anyway... None of those are valid complaints. Where's my 100% damnit

Google.com has 100. Facebook has a 99.

The best I've gotten to (on a real site) is a 98, but I'm quite pleased that I've got a few sites faster than pagespeed.googlelabs.com (95)

Re: Google Page Speed Online

#32

This suggestion from Google especially looks fun: The following publicly cacheable, compressible resources should have a "Vary: Accept-Encoding" header: * http://www.google.com/buzz/api/button.js However, it's a useful tool. It gives me useful suggestions for improving. Anybody knows a simple tool to minify javascript?

I think I've been using the Google PageSpeed Plugin (Firefox only though) to minify JS, CSS and shrink PNGs.

Re: Google Page Speed Online

#33

This suggestion from Google especially looks fun: The following publicly cacheable, compressible resources should have a "Vary: Accept-Encoding" header: * http://www.google.com/buzz/api/button.js However, it's a useful tool. It gives me useful suggestions for improving. Anybody knows a simple tool to minify javascript?

There is also UglifyJS https://github.com/mishoo/UglifyJS which is build on Node.

Here's an ugly GUI for Uglify: http://alexsexton.com/uglifui/

Re: Google Page Speed Online

#34

Rats, they got me: The following cacheable resources have a short freshness lifetime. Specify an expiration at least one week in the future for the following resources: http://www.google-analytics.com/ga.js (1 day)

Heh...

The following publicly cacheable, compressible resources should have a "Vary: Accept-Encoding" header: http://partner.googleadservices.com/.../google_service.js

Re: Google Page Speed Online

#35
post #4

The page Hacker News got an overall Page Speed Score of 86 (out of 100).

I actually don't mind HN taking a while to load. It't not that we have to fight for every new user by aggressively optimizing page load time. Btw. the recent changes to the HN backend already improved the average speed a lot.

Re: Google Page Speed Online

#36
post #7

Hmmm... Contrary to a lot of recommendations I see here on HN (patio11 mainly), they seem to recommend enabling keep-alive.

That's because patio11 is telling you how to keep your site alive under load, while that page is telling you how to decrease your page load times. They're contrary goals in this case. Keep-Alive makes things load faster, but it puts a cap on how many clients can connect to your server before it curls up and dies. It would be ideal if Apache would let you set a high-water limit for Keep-Alive connections after which i…

The best way to handle keepalives is to proxy everything through nginx, which can handle a huge number of connections with very little memory. Turn keepalives on in nginx, turn them off on your app server.

Re: Google Page Speed Online

#40
post #7

Hmmm... Contrary to a lot of recommendations I see here on HN (patio11 mainly), they seem to recommend enabling keep-alive.

That's because patio11 is telling you how to keep your site alive under load, while that page is telling you how to decrease your page load times. They're contrary goals in this case. Keep-Alive makes things load faster, but it puts a cap on how many clients can connect to your server before it curls up and dies. It would be ideal if Apache would let you set a high-water limit for Keep-Alive connections after which i…

This is only true for servers that use separate thread/process for each request... It doesn't apply to event-driven servers (nginx, etc).

I'd even say that keep-alive is always your friend and the longer you can keep connection open the better... Of course there are always OS-level limits (open file descriptors, etc), so you should use LRU-queue on idle keep-alived connections to make sure that you won't run out of resources...

Post reply on HN