Re: [xwiki-devs] Investigation: Page Load Time

Ludovic, First, one of the central performance gainers on the web is the usage of Caches. I see nothing of that mentioned there and it should definitely be mentioned I feel. Providing a system where velocity macros and pages can return that they have not been modified since the given time (that the browser indicates) would make probably more than 50% of the xwiki-loaded pages be instantaneously displayed. This sure should be measured. It'd be a comparison between what would happen if such a clean if-modified-since treatment would exist and what is actually done. Secondly, another area where I think page-delivery time is too often eaten in xwiki is at the lack of streaming. Thus far I can only stream by outputting more velocity. I can't stream from a groovy page that is called and, I fear, quite often velocity still calls toString methods instead of streaming, say, a property value. Again, it would be interesting to analyze this statistically. My claim here, would be that this would lower the memory allocation considerably hence the time taken to process. Thirdly, removing unused JS and CSS is, to me, only one step and it is highly desirable to have (integrated) tools that measure the overlap of various CSS sources. The complexity of the CSS is one of the places where Curriki is probably at its biggest difficulty. Finally, the measures you indicate in this page (and also those that I recommend) seem to be strongly application specific. It would be rather nice to have re-runnable tests so that one can draw possibly different test conclusions as part of an admin toolkit. As a result, the objective of dividing by 2 seems quite artificial to me, though certainly enjoyable; it should be there for each application to apply. paul Le 5 mars 2011 à 10:14, Ludovic Dubost a écrit :