WebKit Cache

John Maton john2011uk at gmail.com
Thu Nov 5 08:39:47 UTC 2015


Guru
Many thanks for all your input which I will evaluate. I have been able to
reduce the initial page load time by a factor of 2 by using url connection
interception and a disc cache, so webkit cannot be caching to disc and I
consider that normal.
However beyond that I cannot make much improvement, the webkit in-memory
cache works too well. I would appreciate the ability to either disable it
or work within it to handle the disc caching, at the moment there is too
much code duplication between my disc cache and the webkit in-memory cache
which causes me some performance loss. Currently I am able to cache all
url's with http headers for Cache-Control, ETag and Expires. Some of these
url's are missed by the webkit and I am able to cache them in-memory but
the gain is marginal because of the code duplication.
Maybe I could work with whoever is going to do the enhancements on
your side?
Best regardsL
John Maton

On Thursday, November 5, 2015, Guru Hb <guru.hb at oracle.com> wrote:

> Hi John,
>
> - Oracle documentation says WebKit has an in-memory cache which can be
> overridden by ResponseCache, this is not the case.
>
> http://docs.oracle.com/javase/8/javafx/embedded-browser-tutorial/overview.htm#JFXWV135
> -- "Other features". Explained below.
> - JDK-8014501 states the problem, but has been flagged "not an issue". Why
> is it not an issue?
>         Handling network cache within the webkit engine would be more
> efficient rather than in java.net.ResponseCache. Currently its marked as
> Enhancement and will be taken forward based on priority.
> - signifant coding around "URL.setURLStreamHandlerFactory" and
> "URLConnection" interception produces a functional cache with significant
> performance gains, but is undone by problems deliberately introduced into
> URLLoader code.
>         i can answer for "deliberately introduced into URLLoader code." :
>
>         Webkit has 3 layer of cache (Memory and Disk based) Memory Cache :
>         1. Network level : storing raw network data, But this feature is
> not implemented for our javafx port.
>         [Its by default provided in webkit2, JavaFX uses single process
> model not the webkit2]
>         2. Cached resource for images, scripts, stylesheets,
> xlsstylesheets and fonts (all resource decoded)
>         3. Page Cache (Entire DOM tree is cached, except the main page)
>         This can be tested with Page forward and Page backward.
>
>         "URLLoader code was setting setUsesCaches(false)" was added while
> fixing JDK-8112030, where webview had duplicate RAW data (in ResponseCache)
> and Decoded data (2 and 3 from above) inside the webcore. We should have
> updated our tutorial well after this fix.
>
> If you have considered below options, then please ignore
> 1. Making single page application and managing context with Z-Order.
> 2. Page navigation with Forward and backward.
> 3. lazy loading JavaScript files based on their first time usage
> 4. Choosing closest CDN for their 3rd party script files.
>
> Thanks,
> Guru
>
> -----Original Message-----
> From: John Maton [mailto:john2011uk at gmail.com <javascript:;>]
> Sent: Saturday, October 17, 2015 3:14 PM
> To: openjfx-dev at openjdk.java.net <javascript:;>
> Subject: WebKit Cache
>
> I have been trying to implement a disc based cache for WebView but with
> only partial success, I am particularly trying to cache the .js javascript
> external files which slow down the loading of javascript web pages a lot.
>
> The Oracle documentation states that:
> "When working with the WebView component, you should remember that it has
> the default in-memory cache.
> It means that any cached content is lost once the application containing
> the WebView component is closed.
> However, developers can implement cache at the application level by means
> of the java.net.ResponseCache class. "
>
> but this is not the case. I implemented an in-memory cache using the
> java.net.ResponseCache class but it is very rarely used by WebView - from
> time to time it stores and retrieves favicon.png from the cache - no
> performance gain.
>
> I confirmed by analysing the net traffic that WebView is not caching, thus
> confirming what is stated in JDK-8014501:
> "While navigating with JavaFX WebView component javafx.scene.web.WebView,
> it was found, that every request retrieves all resources from the server
> each time even if previous activities have just  retrieved the resources.
> This behaviour was verified by capturing and analyzing the network traffic.
> The performance impact is considerable. "
>
> nothing seems to have come out of JDK-8014501, so I then wrote a cache
> handler using "URL.setURLStreamHandlerFactory" to intercept all
> URLConnections to the default sun handler. I had some success with this and
> was able to cache .js javascript files and increase performance
> significantly, but there were bugs on a few web sites, notably Outlook's
> email.
>
> On looking into the way my code was handled, I found for example that the
> URLLoader code was setting setUsesCaches(false) with the following comments
> in the code (at line 279 of URLLoader.java in current 1.8.0_66 code):
>         // Given that WebKit has its own cache, do not use
>         // any URLConnection caches, even if someone installs them.
>         // As a side effect, this fixes the problem of WebPane not
>         // working well with the plug-in cache, which was one of
>         // the causes for RT-11880.
>
> So can somebody out there please give me a heads up on what is really
> going on?
>
>  - Oracle documentation says WebKit has an in-memory cache which can be
> overriden by ResponseCache, this is not the case.
>  - JDK-8014501 states the problem, but has been flagged "not an issue".
> Why is it not an issue?
>  - signifant coding around "URL.setURLStreamHandlerFactory" and
> "URLConnection" interception produces a functional cache with significant
> performance gains, but is undone by problems deliberately introduced into
> URLLoader code.
>
> Thanks in advance for any feedback,
> John Maton
>


More information about the openjfx-dev mailing list