On 6 September 2010 03:01, Sidnei da Silva
<sidnei.da.si...@canonical.com> wrote:
> If I'm allowed to get one suggestion in there:
> On Thu, Sep 2, 2010 at 3:39 PM, Laurence Rowe <l...@lrowe.co.uk> wrote:
> <snip>
>> ----
>> Various components should be move out of Plone and into the WSGI
>> pipeline. This should allow us to share code with other projects.
>> Prime contenders would be:
>>  * Authentication
>>  * Resource registries
> One thing I would like to see, and would likely be a small (though
> effective) improvement, specially for Plone would be:
> * Flushing the Document Early (as described by:
> http://www.stevesouders.com/blog/2009/05/18/flushing-the-document-early/)
> I *think* we should be able to get the whole (or most of the)
> <head></head> tag flushed out to the browser (maybe with
> Transfer-Encoding: chunked, by way of RESPONSE.write() or similar WSGI
> majik). If you think about it, for the great majority of Plone sites
> that part of the page is fairly static, except maybe for the <title>
> tag and some metadata. If we could get it far enough so that the
> browser starts fetching the CSS and JS resources while Plone does it's
> thing to render the rest of the page, it would be a great win already.

I fear this would be difficult to implement.

Before being able to flush we need to be sure of the HTTP status code
and that no more headers need to be sent for example when would we
know to send a 302 redirect to a login form.

Does this work for traversal based systems? In the php example he
cites, flushing before database calls is trivial to implement. By the
point we were in a position to flush, would any time be saved or would
most of the database loads (that cause the worst slowdowns) have
occurred already? ZPT is slow, but Chameleon will bring significant
improvements on template rendering time.

Assuming we were able to flush, would it make any difference to
rendering time if the resources were already cached on the browser? If
resource parsing time is not significant here, ensuring landing pages
are cached in a proxy seems a simpler solution.

Framework-Team mailing list

Reply via email to