4 ms·
Besides asset fetching, do any browsers start rendering pages as chunks come in? EDIT TO ADD: ok, so how does this work if you're page has js/jquery code execu
by callmeed 16y ago
Besides asset fetching, do any browsers start rendering pages as chunks come in?
EDIT TO ADD: ok, so how does this work if you're page has js/jquery code executing on load? (say for js-based navigation and layouts) ... are people gonna see funky stuff before the page is fully loaded and the js is executed?
- mdasen 16y agoYes I believe so. If you want to try this out you can setup a PHP page that puts some content up and then calls sleep(). You'll see that the content that has been processed and sent to the browser is displayed as the rest is processed.
- morganpyne 16y agoTo do this you probably want to ensure that the webserver output buffer, PHP's output buffer, and possibly even the TCP stack buffer (if they are all different sizes) are filled with enough test data to get flushed and sent to the browser before calling sleep(), otherwise you won't see much in the client. On a slightly related note tuning these 3 values and setting them to sizes appropriate for the content you are serving can increase your webservers performance.
- cwp 16y agoflush()
- jrockway 16y agoAbsolutely. They won't do it for application/xhtml+xml, so if you want to see this in action, try sending your page as text/html and then application/xhtml+xml. You'll notice that the XML-based page seems glacial. (Why does this happen? Who knows. I have been using streaming XML parsers since like 1990...)
- true_religion 16y agoI believe its because thanks to the structure of XHTML, you cannot validate a page until all the content has been received.
- jrockway 16y agoThere are streaming XML validators. But who cares? The browser isn't validating HTML as it's rendering it, otherwise the internet would be one big blank page.
- chc 16y agoI think that's the point: Browsers don't bother to validate HTML, but they have to validate XHTML to know whether to pitch a fit about errors as required by the spec.
- masklinn 16y ago> But who cares? The browser isn't validating HTML as it's rendering it, otherwise the internet would be one big blank page. But that's the big difference isn't it? Browsers fix html as they go, but they blow up on XML (as mandated by the XML spec). What would be weirder, seeing the page either render fully or blow up, or seeing a page start rendering and then at some point be replaced by an error message? Of course ideally it would start rendering and keep rendering, never blowing up, but that's not really allowed in XML.
- bct 16y ago
- andrewingram 16y agoYes, I've actually used it before to set up a hacky progress report for batch tasks.
- nate 16y agoI just set up a node.js app recently because it does chunking by default. I noticed Chrome didn't want to render the early chunks. I believe some folks mention that some browsers will only render the chunks if a large enough buffer of chunks come down. But Firefox gladly rendered the early chunks. It's easy enough to setup a response.write("Hello") setTimeout response.end("World") in node to see the chunk rendering in different browsers.
- jacobolus 16y agoThis is sometimes handled at a level lower than than the browser (in the socket APIs browsers are built on). Two or three years ago, anyway, when I was last working on this stuff, the buffer amount in Safari for example depended on OS and OS version. The solution is to just throw half a kilobyte of nothing down the wire before starting to send chunks.