[wp-hackers] output buffering in general and wordpress
Dion Hulse (dd32)
wordpress at dd32.id.au
Thu May 3 01:06:11 UTC 2012
In general, output buffering for any application is suggested against
in web apps.. My only reasoning for why ASP might be different would
be a flame war against ASP devs (or the way things are coded).
Output buffering's only advantage is
1. Gziping the content ( I suspect this is why you'd do it in ASP?)
2. Allowing headers to be sent after the html output starts. (Maybe
this is why ASP does it? If the doc starts with <!DOCTYPE.. with
inline ASP after that, you'll need response buffering to be able to
in general, you wouldn't use PHP Output buffering to enable gzip
anymore, you'll use either the web servers builtin compression, or use
PHP's zlib compression (Which while is still output buffering, it's
not the same as PHP's output buffer functions):
As for the flush counterparts.. it's.. well.. flush(), but if you use
output buffering, it's also ob_flush(), ob_flush_all() and maybe
multiple calls to them (see wp_ob_flush_all() for a wrapper).
tl;dr: Avoid output buffering if at all possible, It's faster for web
apps to send data over the wire as it's generated, saves memory
footprint, saves latency, gets the browser rendering things faster,
On 3 May 2012 10:58, Haluk Karamete <halukkaramete at gmail.com> wrote:
> In ASP, we are advised to turn response.buffer to true. So, that's
> what I do right after forcing variable decs.
> What about in PHP? Do you guys always turn it on?
> How about wordpress? Is it on with WP? If not, are there any issues
> turning it on thru a plug in - or by manually inserting into
> And if there are ASP guys here, what's equivalent of ASP's
> response.flush in PHP?
> Response.flush sends the output of what's been buffered so far to the
> client. That helps browser show input much faster.
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
More information about the wp-hackers