Comments on: the Performance Golden Rule

By: Lucas Sandoval

Lucas Sandoval — Thu, 15 Mar 2012 15:39:18 +0000

hey steve, your high performance web site book will get a update?

By: Ben Daniel

Ben Daniel — Wed, 14 Mar 2012 10:45:30 +0000

Steve – we’ve been talking about the 80 / 20 rule for some time and have tried to follow our thoughts through with a short piece of analysis – http://blog.siteconfidence.com/2012/03/querying-80-20-rule.html.
What’re your thoughts?

By: Ricardo B

Ricardo B — Sun, 19 Feb 2012 23:44:36 +0000

It would be nice if yslow and page speed calculate this measure ( frontend vs backend) If suggest this I am sure tey will both implement this feature.

By: Charles

Charles — Sat, 18 Feb 2012 05:16:40 +0000

Good stuff Steve,once I set up supercache, minify, and browser cache I went from page speed of 65 to 89. Not surprisingly my bounce rate lowered and rankings are improving. Thanks for the detailed info

By: Steve Souders

Steve Souders — Fri, 17 Feb 2012 16:33:57 +0000

@Scott: Please see my reply to @Tony (comment #3). @Fabio is right on (thx!). @Jon: The waterfalls are from WebPagetest.

By: Jon

Jon — Fri, 17 Feb 2012 16:27:09 +0000

Hey, Steve. Awesome post, as usual. Quick question, though…what tool did you use to get the back end and front end times in the waterfalls?

By: Fabio Buda

Fabio Buda — Fri, 17 Feb 2012 14:14:13 +0000

@Scott, you should not consider the time your backend takes to create a js file.

What matters (in Steve analisys) is the time ratio between the first byte and the complete loading of the page.

In my humble opinion this kind of analisys is a little rough but also very useful to know how fast the page will be loaded in your user’s browser because the frontend takes time not only to download external resources but also to parse and compile js files as well as render the page following all CSS rules.

Know the time ratio is useful to make strategic decisions like: What should I optimize? Backend or Frontend?

Obviously you could also consider Backend time for your dynamically generated scripts but you should also analyze ratio between the amount of time a server takes to give a response, network latency and the time a browser takes to parse the script… But this would be another issue.

By: Scott Russell

Scott Russell — Fri, 17 Feb 2012 03:10:13 +0000

@Steve. Further to my earlier comments, take for example JS files. Sometimes these are static files served from apache, other times they may be served from tomcat(static but dynamically served), other times they are dynamically created by tomcat using a backend db(ie subject to full GC). So simply assuming all JS files are static (or indeed dynamic) is an approximation. Was wandering if this is the underlying assumption, that you are allocating static or dynamic based on file type and not on the layer they are served from?
As a rule of thumb, assuming no access to server logs, I make the following assumption, url’s with maximum response times of less than 500ms are static, (this would be combined with knowing that there have been full GC On the backend of >500ms). All very java specific I’m fraid. And again based on a use case of maybe 100 users continuous across two hours or so.

By: Mark Nottingham

Mark Nottingham — Tue, 14 Feb 2012 05:40:33 +0000

I think that back-end perf gets more attention (relatively) because it’s in the developers’ face more.

With common architectures (especially Apache prefork), if you have a slow back end, it directly limits your scalability, and you can’t not know you have a problem; your site goes down, or gets absurdly slow even from a browser that’s on the same ethernet segment as the server.

Front-end is more subtle; the work is on the browser, and to many engineers, if it’s not happening on their CPU, they don’t care. You also have to take network latency and loss into account, which is voodoo to many engineers (especially those that have never administered a server!).

This is changing — thanks both to the front-end perf movement (nod to you, Steve :), but also because back-end architecture is changing too, with non-traditional server architecures like Node.JS. In this approach, the latency of the back-end request doesn’t directly affect scalability, getting one distraction out of the developers’ way (he says, hopefully).

Anyway, good stuff.

By: Steve Souders

Steve Souders — Tue, 14 Feb 2012 05:28:41 +0000

@Scott: These stats are true for both dynamic and static pages. All of the pages in the Top 10, 9990+, and Startups are dynamic and yet still are 76-92% frontend. The bigger difference you raise when discussing a flow (like purchasing a book) is empty cache vs primed cache. These stats are only empty cache. Even primed cache is heavily weighted to frontend. I’ll try to run those stats tomorrow and report back here.

@Sergey: I got a tweet from Tenni about this post. She and I both did that very first presentation at Web 2.0 Expo in 2007. Seems so long ago.