Here's a few experimental additions I made to conf/web.xml to
aggressively target what files have packet header caching parms set by
Tomcat
<filter-mapping>
<filter-name>ResponseHeaderFilter</filter-name>
<url-pattern>/ui/mmi/tools/*</url-pattern>
</filter-mapping>
<filter-mapping>
<filter-name>ResponseHeaderFilter</filter-name>
<url-pattern>/ui/mmi/config/*</url-pattern>
</filter-mapping>
<filter-mapping>
<filter-name>ResponseHeaderFilter</filter-name>
<url-pattern>/ui/mmi/bundle/*</url-pattern>
</filter-mapping>
The filter mapping addition for /bundle/ only works iff
"options.cache=true" is set in CSpaceInfusions.js. This change isn't
approved yet but it appears to work as expected, which is to allow
ajax caching of the html template files in the UI bundle directory.
So, caveat emptor if you choose to use this.
Once implemented I can measure some improvement in page load metrics.
For instance, createnew now only makes two calls: a get to loginstatus
and a post to composite. The page loads in about 320ms (maybe slightly
faster, hard to tell) and transfers roughly 2kb instead of 64kb
without the filter-mapping additions. Page load speeds may not differ
much from before and after but less files to transfer means less
chances for delay. (And less bandwidth used!)
Here's a few experimental additions I made to conf/web.xml to
aggressively target what files have packet header caching parms set by
Tomcat
<filter-mapping>
<filter-name>ResponseHeaderFilter</filter-name>
<url-pattern>/ui/mmi/tools/*</url-pattern>
</filter-mapping>
<filter-mapping>
<filter-name>ResponseHeaderFilter</filter-name>
<url-pattern>/ui/mmi/config/*</url-pattern>
</filter-mapping>
<filter-mapping>
<filter-name>ResponseHeaderFilter</filter-name>
<url-pattern>/ui/mmi/bundle/*</url-pattern>
</filter-mapping>
The filter mapping addition for /bundle/ only works iff
"options.cache=true" is set in CSpaceInfusions.js. This change isn't
approved yet but it _appears_ to work as expected, which is to allow
ajax caching of the html template files in the UI bundle directory.
So, caveat emptor if you choose to use this.
Once implemented I can measure some improvement in page load metrics.
For instance, createnew now only makes two calls: a get to loginstatus
and a post to composite. The page loads in about 320ms (maybe slightly
faster, hard to tell) and transfers roughly 2kb instead of 64kb
without the filter-mapping additions. Page load speeds may not differ
much from before and after but less files to transfer means less
chances for delay. (And less bandwidth used!)
- Jesse