I don't believe you understood my example.
It is the fetching of the main data that will be expensive in my example,
maybe it is the result of many hits to multiple databases, complex join, or
a map reduce.
However the browser also needs to fetch and parse all the other resources
it needs to be able to display the page.
So rather than wait for everything before you deliver the page and then it
still may have to fetch and parse javascript and css after it gets the
page, if you instead were streaming the page and the head went first, then
the browser could be fetching any resources it needs, parsing them and be
ready once the data can be delivered.
We are talking about optimizing the time it takes for the browser to have a
usable page (meaning it has fetched all its resources and parsed them).
If you wait and deliver only a fully rendered template, the browser might
still need to fetch and parse other resources after it receives the HTML,
so there will be a delay and possibly the data could be presented without
style until it has time to fetch and re-render.
Thus with async rendering, you can potentially improve the time it takes to
be ready to use a page by doing things while waiting on others.
On Tuesday, 27 November 2012 10:35:59 UTC-6, Вадим Барышев wrote:
>
> Rendering of templates is very-very fast Task, because it just
> concatenation function. Less than 0.1ms. What wasting time do you mean? You
> can waitng all data, and push it all into template engine. It will be
> faster than if you do it by parts, because synchronous algorithm of
> template engine faster and easier than asynchronous.
>
> вторник, 27 ноября 2012 г., 20:26:56 UTC+4 пользователь Jeff Barczewski
> написал:
>>
>> @Oliver Here is an example where an asynchronous template engine like
>> dust could provide a nice optimization in time to render a page from server
>> to browser.
>>
>> Let's say a dynamic page on the server is rendered from a layout and it
>> depends on several pieces of data from the database all of which can vary
>> from page to page:
>>
>> - javascript
>> - css
>> - main data
>>
>> I can fetch all of them in parallel from one or more databases and as
>> soon as I have the javascript and css, I can start rendering and streaming
>> the head, so the browser can fetch and parse, then when the data is ready,
>> I stream the rest.
>>
>> Assuming the javascript and css data can be fetched more rapidly than the
>> main data (which could be using a complicated query), then I am not wasting
>> time waiting for everything, the browser can be using the time to prepare
>> what it has, then when the final data arrives, it can instantly finish the
>> render.
>>
>> Given this template:
>>
>>
>> <html>
>> <head>
>> {javascript}
>> {css}
>> </head>
>> <body>
>> {mainData}
>> </body>
>> </html>
>>
>>
>>
>> It can stream the template in chunks from the server to the browser,
>> blocking at {javascript} until it has that data, then blocking at {css},
>> then {mainData}.
>>
>> So as the data becomes available, more chunks can be delivered to the
>> browser. Assuming these are all fetched in parallel and that javascript and
>> css return first, we will have a nice optimization by being able to get the
>> browser javascript and css to parse, while it is waiting for the main part
>> of the page.
>>
>> It is mostly useful for rendering templates on the server. If you are
>> rendering on the client, then you will likely be synchronous.
>>
>>
>> Jeff
>>
>
--
Job Board: http://jobs.nodejs.org/
Posting guidelines:
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
