PHP implements BigPipe chunked output_PHP tutorial

In the Yahoo system's best practices, it is recommended to output static content as early as possible, and call flush after the head, so that the browser can load static resources as early as possible, including scripts, styles, images (javascript, css, images are generally external In the form of a chain), etc., if there are multiple data sources or APIs that need to be called in the background, try to complete one output one by one, and assemble the page on the front end through js to achieve the effect of optimizing the user experience. The time the user waits is not worth the time. The fast wooden board with the shortest barrel.
Here is the quote:
Flush the Buffer Early
tag: server
When users request a page, it can take anywhere from 200 to 500ms for the backend server to stitch together the HTML page. During this time, the browser is idle as it waits for the data to arrive. In PHP you have the function flush( ). It allows you to send your partially ready HTML response to the browser so that the browser can start fetching components while your backend is busy with the rest of the HTML page. The benefit is mainly seen on busy backends or light frontends.
A good place to consider flushing is right after the HEAD because the HTML for the head is usually easier to produce and it allows you to include any CSS and JavaScript files for the browser to start fetching in parallel while the backend is still processing.
Example:

...

...
The BigPipe technology proposed by Facebook implements this idea in a more concrete way. The general idea is to decompose web pages into small pieces called Pagelets, and then establish pipelines through Web servers and browsers to manage their operation at different stages.
Do a small test under php,

';ob_flush();flush();sleep(2);echo "b";?>
The results can be seen under IE (7, 8). Regardless of the size of the output content, the effect can be seen. "b" is output after 2 seconds. In Firefox and Chrome, both pieces of text are displayed after 2 seconds. Description The browser has cached it. After experiments, the cache size is 1024, which is exactly 1k. This is also an optimization done by the browser. It can be seen from the return header that when outputting in segments, the return packet does not go through gzip.

Through wireshark, you can see that the background output is indeed chunked one by one. It seems that the browser has done the work. I guess: the cache size should be 1024B or the MTU size (more than 1400B, depending on the network conditions). The first paragraph of output increases to At 1024, Chrome and Firefox started to perform normally, and the js, css and images in the page started loading after the first paragraph was downloaded.

Questions to think about:
1. Transmission efficiency, try to use one transmission to transmit as many things as possible, adjust according to the MTU size;
2. Synchronous loading. The first thing sent should be loaded synchronously as much as possible. You need to pay attention to the number of domain names that different browsers can load synchronously. You need to consider the block loaded by javascript. For content that does not need to be executed immediately, you can add defer or Simply comment it out and wait for the page to be completed before eval comes in;
3. Scope of application. Each technology has its own applicable scenarios. It is more suitable for applications that need to access multiple APIs in the background. For example, social networking websites, searches, etc. are already displayed in about 100ms. It is purely for fun. Technology is meaningless, and the more chunked, the better. Appropriate and similar ones are best combined;
4. ob_flush and flush are best used in pairs. In some cases, flush has no effect.

Reference:

http://www.BkJia.com/kf/201202/118114.html

http://developer.yahoo.com/performance/rules.html#flush

http://www.BkJia.com/kf/201202/118116.html

http://www.BkJia.com/kf/201202/118117.html

http://baike.baidu.com/view/4601904.htm

http://www.BkJia.com/kf/201202/118118.html