Comments on: Reducing the number of page components http://www.phpied.com/reducing-the-number-of-page-components/ Stoyan's blog about <a href="/category/xhtml" class="tag-minor">(x)html(5)</a>, <a href="/category/ajax" class="tag-major">ajax</a>, <a href="/category/bookmarklets" class="tag-major">bookmarklets</a>, <a href="/category/browsers" class="tag-minor">browsers</a>, <a href="/category/css" class="tag-normal">css</a>, <a href="/category/firebug" class="tag-minor">firebug</a>, <a href="/category/javascript" class="tag-numero-uno">javascript</a>, <a href="/category/json" class="tag-normal">json</a>, <a href="/category/mdb2" class="tag-minor">mdb2</a>, <a href="/category/mysql" class="tag-normal">mysql</a>, <a href="/category/pear" class="tag-numero-uno">pear</a>, <a href="/category/performance" class="tag-major">performance</a>, <a href="/category/php" class="tag-numero-uno">php</a>, <a href="/category/phpbb" class="tag-major">phpbb</a>, <a href="/category/tools" class="tag-normal">tools</a>, <a href="/category/yslow" class="tag-minor">yslow</a>, <a href="/category/yui" class="tag-normal">yui</a>, <a href="/category/writing" class="tag-minor">writing</a>, <a href="/category/music" class="tag-major">music</a>,... <a href="/category/life-and-everything" class="tag-normal">life and everything</a>. Sat, 11 Feb 2012 14:07:43 +0000 hourly 1 http://wordpress.org/?v=3.1 By: programs http://www.phpied.com/reducing-the-number-of-page-components/#comment-79723 programs Tue, 15 Nov 2011 05:26:38 +0000 http://www.phpied.com/?p=986#comment-79723 <strong>programs...</strong> [...]Reducing the number of page components / Stoyan's phpied.com[...]... programs…

[...]Reducing the number of page components / Stoyan’s phpied.com[...]…

]]> By: vitre teinté http://www.phpied.com/reducing-the-number-of-page-components/#comment-75540 vitre teinté Sat, 08 Jan 2011 10:52:12 +0000 http://www.phpied.com/?p=986#comment-75540 Well done, the site is much more pleasant to use. Well done, the site is much more pleasant to use.

]]> By: Performance Calendar » Blog Archive » The pain points of having fewer components http://www.phpied.com/reducing-the-number-of-page-components/#comment-74783 Performance Calendar » Blog Archive » The pain points of having fewer components Tue, 30 Nov 2010 19:49:22 +0000 http://www.phpied.com/?p=986#comment-74783 [...] points of having fewer componentsby Stoyan Stefanov Last night I talked about the benefits of reducing the number of page components and the resulting elimination of HTTP overhead. A little carried away into making the case [...] [...] points of having fewer componentsby Stoyan Stefanov Last night I talked about the benefits of reducing the number of page components and the resulting elimination of HTTP overhead. A little carried away into making the case [...]

]]> By: Performance Calendar » Blog Archive » Reducing the payload: compression, minification, 204s http://www.phpied.com/reducing-the-number-of-page-components/#comment-74779 Performance Calendar » Blog Archive » Reducing the payload: compression, minification, 204s Tue, 30 Nov 2010 19:46:13 +0000 http://www.phpied.com/?p=986#comment-74779 [...] the payload: compression, minification, 204sby Stoyan Stefanov After removing all the extra HTTP requests you possibly can from your waterfall, it’s time to make sure that those that [...] [...] the payload: compression, minification, 204sby Stoyan Stefanov After removing all the extra HTTP requests you possibly can from your waterfall, it’s time to make sure that those that [...]

]]> By: Performance Calendar » Blog Archive » DOM access optimization http://www.phpied.com/reducing-the-number-of-page-components/#comment-74769 Performance Calendar » Blog Archive » DOM access optimization Tue, 30 Nov 2010 16:54:52 +0000 http://www.phpied.com/?p=986#comment-74769 [...] access optimizationby Stoyan Stefanov This blog series has sailed from the shores of networking, passed down waterfalls and reflows, and arrived in ECMAScriptland. Now, turns out [...] [...] access optimizationby Stoyan Stefanov This blog series has sailed from the shores of networking, passed down waterfalls and reflows, and arrived in ECMAScriptland. Now, turns out [...]

]]> By: Sci-Fi-Si http://www.phpied.com/reducing-the-number-of-page-components/#comment-72277 Sci-Fi-Si Mon, 08 Feb 2010 16:57:18 +0000 http://www.phpied.com/?p=986#comment-72277 Good post, many thanks. I've been optimising for the past month and still trying to figure which are the best pay-offs'. It's good to know I'm not the only optimising perfectionist... :) Good post, many thanks.

I’ve been optimising for the past month and still trying to figure which are the best pay-offs’. It’s good to know I’m not the only optimising perfectionist…

:)

]]> By: Fabrizio http://www.phpied.com/reducing-the-number-of-page-components/#comment-72203 Fabrizio Mon, 25 Jan 2010 13:28:50 +0000 http://www.phpied.com/?p=986#comment-72203 I'm trying to merge multiple file.js in a single file but some script don't run. I haven't problems when I include js with I did a file with inline script like this: content of file1 content of file1 content of file1 content of file1 but the problems remain... Could you please help me to understand why? I’m trying to merge multiple file.js in a single file but some script don’t run.
I haven’t problems when I include js with

I did a file with inline script like this:
content of file1
content of file1
content of file1
content of file1
but the problems remain…

Could you please help me to understand why?

]]> By: Daniel http://www.phpied.com/reducing-the-number-of-page-components/#comment-71888 Daniel Sat, 05 Dec 2009 15:31:58 +0000 http://www.phpied.com/?p=986#comment-71888 I quite agree with Kyle. But I still have some concerns about combining js files. Of course, if we can combine all js files into 1 big file, it will improve performance, but it will also hurt the browser's cache. For example, the first page contains 1.js, 2.js and 3.js, and combine them to all.js. So the browswer will get all.js and cache it. But for the second page which may only contain 1.js and 2.js, browser will need to fetch them again. So it is not quite easy for us to find which files should be combine together. We need to balance between two perspectives: 1) most common files across all pages 2) combine as more files as possible What's your best practice about this issue? How to find the best strategy to combine js and css files? I quite agree with Kyle. But I still have some concerns about combining js files. Of course, if we can combine all js files into 1 big file, it will improve performance, but it will also hurt the browser’s cache. For example, the first page contains 1.js, 2.js and 3.js, and combine them to all.js. So the browswer will get all.js and cache it. But for the second page which may only contain 1.js and 2.js, browser will need to fetch them again.

So it is not quite easy for us to find which files should be combine together. We need to balance between two perspectives:
1) most common files across all pages
2) combine as more files as possible

What’s your best practice about this issue? How to find the best strategy to combine js and css files?

]]> By: Kyle Simpson http://www.phpied.com/reducing-the-number-of-page-components/#comment-71887 Kyle Simpson Sat, 05 Dec 2009 14:53:54 +0000 http://www.phpied.com/?p=986#comment-71887 This is a very good article overall. Certainly, it's becoming more and more important to reduce not only the amount of unnecessary content sent to pages (at least at initial page-load), but also optimize how the necessary stuff is transferred. Far too long, those things were only cared about by the jumbo major traffic sites, but now we know all of us have that responsibility, for the betterment of user-experience. However, I still have to take slight issue with the concept of combining as much content as possible into a single stream of data. Yes, we need to reduce unnecessary HTTP requests and overhead -- I just saw yesterday a profile of a page-load from a major online kids toy retailer that had over 60 different http requests, which is of course RIDICULOUS! But I just don't think that "1" is the ultimate best goal. I think there needs to be a balance between reducing HTTP requests and: 1. parallel byte download streams (for instance, loading JavaScript in parallel with LABjs) -- if you take one 100k file and download it as two 50k files, it'll download (in theory) in half the time, but then factoring in HTTP request overhead, it might go to 2/3 or 3/4 the time. But the point is, for these larger resources, it's still likely to download faster in parallel than the single stream would have come down serially. 2. caching: not just caching during a single visit, but also caching across visits (say over a week, or even a month). Yes, I know that the browser cache is not reliable, and a non-trivial amount of people come with no primed cache at all. BUT, that doesn't mean, IMHO, that the cache is moot -- it's still a very important piece of the puzzle. For instance, if you have 4 JS files you concat into 1, and it's now 100k in size... and then you realize that a few lines of that JavaScript are likely to be changed more often (say because you are tweaking UX/animations, or fixing bugs in new code, etc), if you change even one single byte of that combined file, then every single visitor will have to redownload the other 99.999k unnecessarily the next time they visit. So, maybe we should profile and keep our JS in 2 files (or perhaps 3), based on factors like likelihood to change (for instance, frameworks and plugins *rarely* change, but the code which uses them is more likely to change as you tweak your site). You may pay slight costs in extra overhead on first page views, but over the life of your site and your visitors re-visits to your site, you will probably see better overall page-load performance. This may not be most important, but it's not something to be completely forgotten either. I've written up a bunch of thoughts in more detail on this topic over on this post, if you are interested in digging more into detail on concat'ing resources: http://blog.getify.com/2009/11/labjs-why-not-just-concat This is a very good article overall. Certainly, it’s becoming more and more important to reduce not only the amount of unnecessary content sent to pages (at least at initial page-load), but also optimize how the necessary stuff is transferred. Far too long, those things were only cared about by the jumbo major traffic sites, but now we know all of us have that responsibility, for the betterment of user-experience.

However, I still have to take slight issue with the concept of combining as much content as possible into a single stream of data. Yes, we need to reduce unnecessary HTTP requests and overhead — I just saw yesterday a profile of a page-load from a major online kids toy retailer that had over 60 different http requests, which is of course RIDICULOUS! But I just don’t think that “1″ is the ultimate best goal. I think there needs to be a balance between reducing HTTP requests and:

1. parallel byte download streams (for instance, loading JavaScript in parallel with LABjs) — if you take one 100k file and download it as two 50k files, it’ll download (in theory) in half the time, but then factoring in HTTP request overhead, it might go to 2/3 or 3/4 the time. But the point is, for these larger resources, it’s still likely to download faster in parallel than the single stream would have come down serially.

2. caching: not just caching during a single visit, but also caching across visits (say over a week, or even a month). Yes, I know that the browser cache is not reliable, and a non-trivial amount of people come with no primed cache at all. BUT, that doesn’t mean, IMHO, that the cache is moot — it’s still a very important piece of the puzzle.

For instance, if you have 4 JS files you concat into 1, and it’s now 100k in size… and then you realize that a few lines of that JavaScript are likely to be changed more often (say because you are tweaking UX/animations, or fixing bugs in new code, etc), if you change even one single byte of that combined file, then every single visitor will have to redownload the other 99.999k unnecessarily the next time they visit.

So, maybe we should profile and keep our JS in 2 files (or perhaps 3), based on factors like likelihood to change (for instance, frameworks and plugins *rarely* change, but the code which uses them is more likely to change as you tweak your site). You may pay slight costs in extra overhead on first page views, but over the life of your site and your visitors re-visits to your site, you will probably see better overall page-load performance. This may not be most important, but it’s not something to be completely forgotten either.

I’ve written up a bunch of thoughts in more detail on this topic over on this post, if you are interested in digging more into detail on concat’ing resources:

http://blog.getify.com/2009/11/labjs-why-not-just-concat

]]> By: Allogarage http://www.phpied.com/reducing-the-number-of-page-components/#comment-71885 Allogarage Sat, 05 Dec 2009 14:17:08 +0000 http://www.phpied.com/?p=986#comment-71885 Thanks for the summary. I already implement css and jss minification+concatenation on deployment, but I never heard about mixing js and css. Seems to be simple, I will make some tests. Thanks for the summary. I already implement css and jss minification+concatenation on deployment, but I never heard about mixing js and css. Seems to be simple, I will make some tests.

]]>