Why use output buffering in PHP?
http, php
Solution
Yes
Serious web applications need output buffering in one specific situation:
Your application wants control over what is output by some 3rd-party code, but there is no API to control what that code emits.
In that scenario, you can call `ob_start()` just before handing control to that code, mess around with what is written (ideally with the callback, or by examining the buffer contents if you must), and then calling `ob_flush()`.
Ultimately, PHPs' ob_functions are a mechanism for capturing what some other bit of code does into a buffer you can mess with.
If you don't need to inspect or modify what is written to the buffer, there is nothing gained by using `ob_start()`.
Quite likely, your 'serious application' is in fact a framework of some kind.
You already have output buffering, anyway
You don't need `ob_start()` in order to make use of output buffering. Your web-server already does buffer your output.
Using `ob_start()` does not get you better output buffering - it could in fact increase your application's memory usage and latency by 'hoarding' data which the web-server would otherwise have sent to the client already.
Maybe `ob_start()` ...
... for convenience when flushing
In some cases, you may want control over when the web-server flushes its buffer, based on some criteria which your application knows best. Most of the time, you know that you just finished writing a logical 'unit' which the client can make use of, and you're telling the web-server to flush now and not wait for the output buffer to fill up. To do this, it is simply necessary to emit your output as normal, and punctuate it with `flush()`.
More rarely, you will want to withhold data from the web-server until you have enough data to send. No point interrupting the client with half of the news, especially if the rest of the news will take some time to become available. A simple `ob_start` later concluded by an `ob_end_flush()` may indeed be the simplest and appropriate thing to do.
... if you have responsibility for certain headers
If your application is taking responsibility for calculating headers which can only be determined after the full response is available, then it may be acceptable.
However, even here, if you can't do any better than deriving the header by inspecting the complete output buffer, you might as well let the web-server do it (if it will). The web-server's code, is written, tested, and compiled - you are unlikely to improve on it.
For example, it would only be useful to set the `Content-Length` header if your application knows the length of the response body after before it computes the response body.
No panacea for bad practices
You should not `ob_start()` to avoid the disciplines of:
- opening, using and quickly closing resources such as memory, threads and database connections
- emitting headers first, and the body second
- doing all the calculations and error handling you can, before beginning the response
If you do these, they will cause technical debt which will make you cry one day.
Problem
I have read quite a bit of material on Internet where different authors suggest using output buffering. An interesting thing is that most authors argument for its use only because it allows for mixing response headers with actual content. I think that Web applications crossing certain size / complexity threshold should not mix generating headers and content, and that the developer should rightfully suspect potential faults in applications that attempt to send headers after body has been generated. This is my first argument against the `ob_*` output buffering API. Even for that little convenience you get - mixing headers with output - I believe it isn't worth it, unless one simply is rapidly "hacking" or "prototyping" scripts. Also, I think most people dealing with the output buffering API do not think about the fact that even without the explicit output buffering enabled, PHP in combination with the Web server it is plugged into, still does some internal buffering anyway. It is easy to check - have a script echo some short string, then sleep for say 10 seconds, then do another echo. Go to the script URL with a Web browser and watch the blank page pause for 10 seconds, with both lines appearing thereafter. Before some say that it is a rendering artefact, not traffic, tracing the actual traffic between the client and the server shows that the server has generated the `Content-Length` header with an appropriate value for the entire output - suggesting that the output was not sent progressively with each `echo` call, but accumulated in some buffer and then sent on script termination. This is one of my gripes with explicit output buffering - why do we need two different output buffer implementations on top of one another? May it be because some of it is subject to conditions a PHP developer cannot control, so another means to control it is put into PHP? In any case, I for one, start to think one should avoid explicit output buffering (the series of `ob_*` functions) and rely on the implicit one, assisting it with the good `flush` function, when necessary. Maybe if there was some guarantee from the Web server to actually commit output to the client with each echo/print call, then it would be useful to set up explicit buffering - after all one does not want to send response to the client with some 100 byte chunks. But the alternative with two buffers seems like a somewhat useless layer of abstraction. With all this in mind, why use output buffering?