[TYPO3-core] RFC #17167: Cache ExtDirect::getAPI calls

[Ernesto Baschny [cron IT]]

Steffen Gebert schrieb am 21.01.2011 19:51:
>> header_remove('Last-Modified');
>>
>> And it seems to have helped, no more calls to ExtDirect::getAPI when
>> clicking around. Only when one do a explicit "reload" of the whole
>> backend, all those resources are fetched again (which caused me some
>> time to figure out that it works differently between clicking around and
>> hitting reload...).
>>
>> So I would say, we commit this follow-up (PHP 5.2 compatible). Could you
>> last-check it and do it, please, Steffen? Thanks!
> 
> Hi,
> 
> I've been discussing with Stefan for a while now. He pointed me to
> Google Page Speed > Optimize Caching page [1]
> 
>> It is important to specify one of Expires or Cache-Control max-age,
>> and one of Last-Modified or ETag, for all cacheable resources. It is
>> redundant to specify both Expires and Cache-Control: max-age, or to
>> specify both Last-Modified and ETag.
> So, we should better not remove that header.
> 
> Situation is a bit weird:
>> Expires and Cache-Control: max-age. These specify the “freshness
>> lifetime” of a resource, that is, the time period during which the
>> browser can use the cached resource without checking to see if a new
>> version is available from the web server. They are "strong caching
>> headers" that apply unconditionally; that is, once they're set and
>> the resource is downloaded, the browser will not issue any GET
>> requests for the resource until the expiry date or maximum age is
>> reached.
> That's the situation, we currently have. However, the browser *does*
> these requests.
> 
> Furthermore, they state
>> If the Last-Modified date is sufficiently far enough in the past,
>> chances are the browser won't refetch it.
> So.. what is old enough? I tried setting the Last-Modified header to -1
> year. However, Chrome still asked the server and got a 304 response (I
> was working with static files, but for the ExtDirect thing, this would
> be a normal 200 response containing the full content).
> 
> So.. the solution we had looked pretty good.. however.. google says that
> we're doing bad things.
> 
> W.r.t the situation of being pretty close to RC1 and final: Keep it as
> is and find out during development of 4.6, whether this is good or not.

I just checked, and its not related to Last-Modified being there or not.
We already got good improvement in that area, I think this is nearly
optimal as it is. Thanks for investigating!

The other matter is that parsing and executing the whole ext-all.js
takes very long time (at least for Firefox 3), and this is currently the
last left performance issue of the backend.

A solution would be not to load those ExtJS files on every IFRAME, but
that would require accessing them from "top.*" if available. I don't
think we will come with a solution in time for RC1, but deserves some
investigation, as it would spare around 400ms on every hit (on FF3,
maybe more on IE8). Issue is not so dramatic with FF4 (and Chrome),
which probably do some caching of once parsed scripts.

Cheers,
Ernesto