Comments on: the Performance Golden Rule http://www.stevesouders.com/blog/2012/02/10/the-performance-golden-rule/ Essential knowledge for making your web pages faster. Wed, 29 Oct 2014 12:31:39 +0000 hourly 1 http://wordpress.org/?v=3.7.4 By: Lucas Sandoval http://www.stevesouders.com/blog/2012/02/10/the-performance-golden-rule/#comment-3780 Thu, 15 Mar 2012 15:39:18 +0000 http://www.stevesouders.com/blog/?p=2436#comment-3780 hey steve, your high performance web site book will get a update?

]]>
By: Ben Daniel http://www.stevesouders.com/blog/2012/02/10/the-performance-golden-rule/#comment-3779 Wed, 14 Mar 2012 10:45:30 +0000 http://www.stevesouders.com/blog/?p=2436#comment-3779 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 http://www.stevesouders.com/blog/2012/02/10/the-performance-golden-rule/#comment-3756 Sun, 19 Feb 2012 23:44:36 +0000 http://www.stevesouders.com/blog/?p=2436#comment-3756 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 http://www.stevesouders.com/blog/2012/02/10/the-performance-golden-rule/#comment-3753 Sat, 18 Feb 2012 05:16:40 +0000 http://www.stevesouders.com/blog/?p=2436#comment-3753 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 http://www.stevesouders.com/blog/2012/02/10/the-performance-golden-rule/#comment-3749 Fri, 17 Feb 2012 16:33:57 +0000 http://www.stevesouders.com/blog/?p=2436#comment-3749 @Scott: Please see my reply to @Tony (comment #3). @Fabio is right on (thx!).

@Jon: The waterfalls are from WebPagetest.

]]>
By: Jon http://www.stevesouders.com/blog/2012/02/10/the-performance-golden-rule/#comment-3748 Fri, 17 Feb 2012 16:27:09 +0000 http://www.stevesouders.com/blog/?p=2436#comment-3748 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 http://www.stevesouders.com/blog/2012/02/10/the-performance-golden-rule/#comment-3747 Fri, 17 Feb 2012 14:14:13 +0000 http://www.stevesouders.com/blog/?p=2436#comment-3747 @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 http://www.stevesouders.com/blog/2012/02/10/the-performance-golden-rule/#comment-3746 Fri, 17 Feb 2012 03:10:13 +0000 http://www.stevesouders.com/blog/?p=2436#comment-3746 @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 http://www.stevesouders.com/blog/2012/02/10/the-performance-golden-rule/#comment-3744 Tue, 14 Feb 2012 05:40:33 +0000 http://www.stevesouders.com/blog/?p=2436#comment-3744 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 http://www.stevesouders.com/blog/2012/02/10/the-performance-golden-rule/#comment-3743 Tue, 14 Feb 2012 05:28:41 +0000 http://www.stevesouders.com/blog/?p=2436#comment-3743 @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.

]]>