(Note: See “Output-Buffering and Extensible WordPress Plug-Ins” for an update to the below that substantially revises my conclusions.)
I asked the following question at Stackoverflow today: “PHP output buffering: When/whether to use for different kinds of real existing sites and applications?”
So far, I’ve gotten one answer tending to confirm my general inclination not to use it for the kinds of scripts in which I’m interested.
The following is the full text of my “question”:
Working mainly in WordPress contexts, I have mostly done without output buffering in my PHP code, but I have recently begun to experiment with it and try to discern simply as a user whether there was any noticeable performance impact in typical (for me) scenarios. Can’t say I’ve achieved anything definitive there, but I don’t know that my experiments really apply to scaled-up situations.
My general impression is that, unless I have a very good reason for using it – probably involving the kind of script in which I’m not generally interested at this time – I should avoid it. Yet I’ll read suggestions that I could use buffering in one or another normal context (e.g., a shortcode that renders a large block of HTML), and I often see it being used in code by people whose work I admire and try to emulate. I’ve seen the familiar ob_start() etc. sequences applied for rendering even very minimal output that is not further adjusted: a menu or other short list, for example.
I have also seen people assert that there is simply no need for output buffering in well-written code, except in peculiar situations. See StackOverflow Q&A’s here Why use output buffering in PHP?, to give one example. Others will say it’s useful ONLY when some manipulation of the output is necessary – like a preg_replace of content – but you don’t need an output buffer to do that kind of thing (any ol’ variable will do).
In most real world instances of the sort I encounter, some version of page caching will also be in use, and sometimes several different plug-ins each with its own caching. Considering how many functions will themselves employ numerous nested/secondary HTML-producing functions, you could easily produce thousands of little nested buffered blocks per page: Suppose a foreach loop produces n number of blog-comments within a larger page: Each blog-comment is rendered by a function, and could be buffered separately. The each-comment function could be called within the foreach loop of the function that outputs the comment thread, and its output could also be buffered. Then the function that outputs the post that includes the comment thread could be output-buffered before being rendered. The entire page, including sundry independently output-buffered templates, plug-ins, widgets, menus, etc., etc., could also be output-buffered.
At what point would any of it be useful or, alternatively, completely counterproductive?
If the answer involves any element of “well, you wouldn’t notice in your blog, but you’d need it for BuzzFeed or the New York Times,” or the reverse, how would I estimate when the point has been reached?
At this point, I’m leaning toward writing the code as cleanly as possible, and letting (what I understand to be) built-in PHP, browser, server, etc., buffering and explicit caching functions do the work of making the page or its elements load efficiently and quickly, which is the real objective, no?