I use object buffering to buffer the output of my php pages using ob_start('ob_gzhandler');.
Does this affect the performance of the files stored in CDN?
The reason for asking this question is because, one of the site indicated the following about "Output buffering is a simple way to greatly improve the performance and speed of your PHP script. Without output buffering, your script will show the HTML on the page as it’s processed – in pieces. Adding output buffering allows the PHP to store the HTML as a variable and send it to the browser in one chunk."
Could you please clarify?
Using ob_start certainly will affect the load times of your pages -- not "the performance of your PHP script", which is IMHO a totally misleading expression. But let's take things from the beginning.
The side you mention seems to refer to page load time as perceived by the user. That is, assume that you have 10KB of HTML to send and you send 1KB every 50ms. Also assume that the browser is not putting any of its own logic in the process and it simply renders as fast as it can read the incoming data (which is certainly not true!). 50ms is long enough to be perceived by a human, so the user will see the page loading piece by piece.
On the other hand, assume that all 10KB of HTML is sent in one go after 500ms. While this will result in the user waiting for the same total amount of time, the page will render in one fell swoop and this will be perceived by the user as being faster because "it spent less time being loaded".
I should also mention that if you take the exact same example and increase the load time to 5 sec (or 10 pieces of .5 sec) then the user perception will be reversed: now the second page is slower because "it took so long to get going".
Clearly this kind of analysis ventures well into the realm of psychology so I 'm going to stop here and suggest that if you are interested in this stuff there is good material available on the web. This is the reason that browsers do put in their own special sauce in the process of rendering the page as data is received: each vendor wants to make their browser feel faster, even though as far as the network is concerned they are all equally fast.
Let's also consider the server side. Anything on the web server stack -- Apache, PHP, anything in between -- can also choose to buffer up data before sending it. Oftentimes this happens even without being explicitly documented or requested by the developer, which is the reason that you will see code that should have presented "headers already sent" notices not do so.
Now if you do buffer things on the server side, what you are really doing is forcing the browser to adapt to your idea of how things should work. Let's go back to the client-side rendering example and consider a browser that receives HTML in small chunks but chooses to delay rendering in order to appear snappier. Doing so does not mean the browser has to do nothing during the delay; indeed, it will most probably parse the HTML and start loading dependencies (stylesheets, images, etc) immediately, even though it does not intend to render the page just yet. This is logical: by being up-front it will end up having the content of these assets available earlier and win the "perceived speed" war.
The problem is, if you assume military command of buffering the browser can no longer do that. It has to wait for the content to be sent and then start looking for these assets. Since we 're talking about a CDN, fetching the assets will be very fast if not instantaneous (due to caching) but that's still a small to zero delay you did not have to suffer.
Of course then we have to take into account that output buffering with the intent of compressing can make the page actually load faster because there's just less data to be sent. The difference will be especially noticeable to people with slow connections.
If you have measured that compression makes a big difference in how fast your pages load, then use it. If you are not compressing, don't try to second-guess browser vendors (who have spent uncountable resources on studies) on the advice of sites with unknown credentials.