Hacker News new | ask | show | jobs
by troels 5368 days ago
It's fairly basic stuff this, but important none the less.

Kudos for recommending Yslow (or PageSpeed) - it's indeed brilliant. You didn't mention much about http caching, which I think is probably as important as the other things you mentioned; Not only does it improve performance for the user, but it also reduces load on your server and it enables you to put up an edge side cache for extra performance.

As for the problems mentioned with the load balancer - You could have simply provisioned a new instance and installed your own load balancer. There's dedicated packages like haproxy, but you could also just put up nginx or lighthttpd. This machine can later double as your edge cache (Squid).

Btw. 1.5s to render the front page? That's way beyond acceptable, in my book. But I suppose it depends a bit on what the web site does.
1 comments
dasil003 5368 days ago
> Btw. 1.5s to render the front page? That's way beyond acceptable, in my book. But I suppose it depends a bit on what the web site does.

Agreed. This will have an extremely negative impact on your user engagement. Now if this is measuring end user response time rather than server-side page generation it might not be quite so bad, but generally I think most common pages should target < 150ms.

link
lowglow 5368 days ago
So what would you both consider "the next steps" in page speed optimizations?
link
sjwright 5367 days ago
If you really do have a legitimate 1500 msec process occurring on the home page, try to flush as much of the HTML to the browser before you start the heavy lifting. Ideally, you could have the entire HTML shell delivered immediately, and the content elements slotted in at the very end (using DOM manipulation).

If you can put all the content inside a <script/> tag at the very end of the HTML, it will at least give the browser a chance to find and download all the page's resources (css, Jquery, logo image, etc etc).

e.g.

  <html>
  <head><link rel="stylesheet"></head>
  <body>
    <h1>Home Page</h1>
    <p id="content1">cheap content</p>
    <p id="content2">place-holder content</p>
    <p id="content3">more content</p>
  ~~flush~~
    <script>
    $("#content2").html("expensive content");
    </script>
  </body>
  </html>
link
troels 5368 days ago
Make sure that http cacheability is good (send proper http headers, e-tag and expires; serve assets from cookie-less sub-domain). But if the page renders in 1.5 secs, I would try to address that also. That's highly specific to the application and its technical platform, so I couldn't really say how to approach that - But break out a profiler and go for the big chunks for a start.
link
dasil003 5368 days ago
Impossible to say without looking at the profiled request. One thing I can say it's I would look at any page-level / HTTP caching until page generation is at least under 300ms for the most common requests.
link