Does ob_start affect performance of files stored on CDN?

Question

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?

Answer 1

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.

User-perceived load time

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.

Output buffering

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.

TL;DR version

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.

Answer 2

When you generate a a page using php, you generate a text file, usually you use echo to render the html. So the ouput page that will be sent by to the client is created in pieces at the rythm of your 'echo'.

When you use buffering the echo render in a memory buffer (that can be called next with ob_get_content for example). And when you need to provide an ouput for the client, you print out the content of the buffer in one operation.

So to make it simple: The write operation on default output is slow, however write operation in memory buffer is faster. So you render in memory buffer then echo the block on default output and you will improve the output speed.

The other benefit is that it allow you to create your how custom cache system.

I don't know what is you use of CDN, but if it is to store images, it is not affected by php buffering.