How to make a site really freaking fast | Hacker News Reader

How to make a site really freaking fast

portent.com

30 pointsportentint37 comments

I don't know. The landing page http://www.portent.com/ is painfully slow for me. The optimization listed are mostly frontend optimization. The first thing I would do is to figure out the bottleneck.

    curl -w "\nTotal time: %{time_total}\nTime pretransfer: %{time_pretransfer}\nTime starttransfer:             %{time_starttransfer}\nSize download: %{size_download}\nSpeed download: % {speed_download}\n" http://www.portent.com/

    Total time: 2.629
    Time pretransfer: 0.375
    Time starttransfer: 1.400
    Size download: 32730
    Speed download: 12449.000

Ok. Not bad. Backend seems to be fine. But then I did the profiling in chrome. Some cdn requests are well past 25 seconds in the timeline. For a user, the site load takes more than 25 seconds. Your cdn is the bottleneck - you should work on fixing the cdn first.

Curl is incredibly useful. However, I noticed that your line above was truncated prematurely.

curl -w "\nTotal time: %{time_total}\nTime pretransfer: %{time_pretransfer}\nTime starttransfer: %{time_starttransfer}\nSize download: %{size_download}\n Speed download: %{speed_download}" www.example.com

I hate how overhyped this article is. It should be titled something like "five basic tweaks to speed up your LAMP webpage". Instead, they're hyping it up as if they'd written their own custom http daemon.

Don't mean to overhype, xamuel. For us non-geeks, this is pretty mind-boggling stuff.

> When I first turned this on, I set the directive in the configuration file to “Conneption: Keep Alive.” Apache began laughing hysterically at my typing skills, and promptly crashed

So a syntax error is now a "crash?". Web developers...

Today I learned people reboot apache without doing `apachectl -t` first.

apachectl -t?

Why go ghetto? You should be doing something like "/sbin/service httpd restart".

I believe he was testing the config, not restarting the server.

`apachectl -t` checks the .conf files for syntax errors.

For this reason, there's zero excuse for ever having an Apache install crash from a typo.

We have Apache running on some Windows boxes-- haven't found a way to run apachectl on Windows...

`apache.exe -t` according to http://www.zrinity.com/developers/apache/usage.cfm

Oops, sorry, meant:

  service httpd configtest

I.e run the proper init script (which might also do other checks), not just test the apache config, as you wouldn't also just start apache with apachectl.

Even if you have your own version of apache compiled, you should still provide your own init script, and write in in the standard service way.

The Apache config test does not catch every error and you can still cause crashes if you don't check it over by hand.

> You should be doing something like "/sbin/service httpd restart".

The 'service' equivalent is: service httpd configtest

> Why go ghetto?

What does 'going ghetto' mean exactly?

>The 'service' equivalent is: service httpd configtest

Yep, typo-ed it.

>What does 'going ghetto' mean exactly?

The slang meaning of the term in this case: a low level, jury rigged solution.

Lots of production installations don't use distro-supplied binaries for their critical services (and there are lots of good reasons for doing this). They generally won't work with (or have) the distro-supplied initscripts.

Note that systemd makes it a lot cleaner and simpler to supply your own service definitions, so eventually your intuition will probably be right, and systemctl will be the proper interface to everything.

Aren't these just standard website speedup techniques? If you ran YSlow on the site, then it's probably going to give you the same advise, but in more detail. And it won't miss obvious suggestions like combine the scripts/css into one file!

pretty sure pagespeed tells you to minimize http requests. that's one of the top things. one of the points from what i remember was to combine js and css files.

The site is still slow, but at least it's a start.

There are still quite a few external scripts loading in the head that have the potential to block the page. The waterfall diagram from a test at webpagetest.org [1] shows a pretty dramatic example. It's not hard to load the Google PlusOne script async [2], and most of the other social network widgets can be lazy-loaded the same way.

[1] http://i.imgur.com/niDK1.png http://i.imgur.com/MLdj8.png [2] https://developers.google.com/+/plugins/+1button/#async-load

And a great way to see if your site is getting faster or not is Blitz: http://blitz.io/

Not impressed at all... the site is quite slow. Way to toot your own horn.

Um, you did make it really fast? Your site is pretty slow to me.

You missed:

- Write compact efficient CSS (arguably the current CSS file is far too big)

- Combine all CSS files

- Don't use question marks in a resource URL (.css?v=234)

- Write valid compact efficient HTML (duplicate meta tags like: ICBM, unnecessary tags like Google verify, inline CSS, depricated HTML: align="left")

- Dont use spacer divs (div clear="all" style="padding-top: 5px") for a better render flow

- Delay loading javascript to the body of your site.

- Combine javascript files

- Compress javascript and CSS files.

- asynchronous loading of web fonts and analytics code.

- Load all CSS files before JS files.

For the unoptimized 1000 images you can use a Wordpress plugin or roll your own batch script.

"- Don't use question marks in a resource URL (.css?v=234)"

why? if you get the cache headers right, this is the way to go to let it cache forever. that's a nice thing.

(i don't really get why they do not use a caching proxy in front, there even is a wordpress plugin for varnish, so wordpress behind a caching proxy does not suck that much.)

unfortunately some suggestions are not possible with wordpress, so that alone could be a thing worth replacing.

we're moving from apache to nginx + php-fpm + apc on linode. as well as all the stuff recommended by pagespeed. jquery cdn, gzip, css sprites, pngcrush, js-min + concat, css concat, async script loading via LABjs. the improvement is quite remarkable. sometimes i blink and miss the F5 refresh flash and wonder if the page actually reloaded. craziness.

one funny thing pagespeed tells me is that google's own analytics ga.js needs a longer expire time than 2hrs, they should fix that especially for scripts loaded from common cdns (especially their own) since web authors have no control over this.

Well, that's one way, certainly. http://cl.ly/402Y0p1028262I0Q2p12

To make a site really, really freaking fast serve static content.

That cool curl command against rakeroutes.com:

    Total time: 0.439
    Time pretransfer: 0.175
    Time starttransfer: 0.270
    Size download: 17506
    Speed download: 39888.000

That's off a regular ol' shared Dreamhost account.

The delicious irony is that I see a database connection error on the page.

Well, of COURSE as soon as I say we made it faster, we screw something up. It's some kind of blogging rule.

The same applies for when you have to demo something to your boss that you just tested 50 times, and of course it crashes on the first try when you demo it!

It seems the site is down. At least I cant get to it from Chile.

The pingdom tests only check the HTML delivery, don't they? So the full page does not load in 1 or 2 seconds.

> Error: Cannot establish a database connection.

Aaaaand I think we're done here.

Well it works razor fast for me, so congratulations.

Or you know, you could not use apache.

Or WordPress...

Be aware of the potential downside to setting very long "expires" headers. There are sometimes caches deep in the darknesses of the Internet that obey these, which can cause havoc if you redesign and reuse any filenames (for instance logo.png).

We've had situations where a site appeared broken to a subset of end users for weeks because we tweaked the look and feel, and the new logo (different size and look) was named logo.png just like the old logo...which had an "expires" header of about one month.

So even after clearing all local and server-side caches, some users were getting our new HTML with our old logo horribly jammed into it--dutifully being served from some unknown cache somewhere until it hit the "expires" time.

Reply on news.ycombinator.com