Caching js_resolve_modules calls

Issue

  • The load time and the amount of data that is requested from the server by caching resolved_modules should be reduced.

Environment

  • Liferay 7.2 with DXP-8

Resolution

  • A hotfix has been provided and below is the explanation of how it works

      • The hotfix is not depending on any browser. The fix allows the browser to cache the resolve_modules responses.

      • Let's say, there are two browsers Firefox and Chrome
        In the case of Firefox, the request header includes Cache-Control: max-age:0, which forces the browser to ask if the given resource is modified on the server or not. When the condition fails (the resource is not modified) for GET and HEAD methods, then the server must return HTTP status code 304 (Not Modified). After this, the resource is served from the cache.

        On Chrome the header includes If-None-Match:"<etag_value>" in the header, this as well makes the request conditional. For GET and HEAD methods, the server will send back the requested resource, with a 200 status, only if it doesn't have an ETag matching the given ones. When the condition fails for GET and HEAD methods, then the server must return HTTP status code 304 (Not Modified).

      • At this point, Chrome decides to send back a status code "200", even when the server sends back a status code 304. This is an "issue" with Chrome itself and has nothing to do with Liferay, "Chrome shows 200 ok even if server returns 304".
        Having said that, caching still works, and the resources are served from the cache at both Chrome and Firefox.

      • The hotfix improved the loading time of this resource by approx 300times.

Additional Information

 

 

 

この記事は役に立ちましたか?
0人中0人がこの記事が役に立ったと言っています