I've played with this package over weekend and I've spot some improvements that can be done in area of efficient content serving.
So I've started analyzing whether this package supports my use case, which is basically just serving assets and adding cache busting query tag to generated links - which seemed to be working fine.
While I am focused on performance in production environment I've applied standard techniques:
response caching (avoid computing bundled content over and over again) - I am relying on my use case where deployments are immutable; so I want to avoid cost of bundling resources more than once.
In general this should boost performance, however it was not the case with this package; after closer inspection (turning log level to trace) I was getting following log lines:
info: WebOptimizer.AssetBuilder[1001]
Responding from memory cache for '/js/bundle.js'
trce: Microsoft.AspNetCore.ResponseCompression.ResponseCompressionProvider[6]
Response compression is available for this Content-Type.
dbug: Microsoft.AspNetCore.ResponseCompression.ResponseCompressionProvider[8]
The response will be compressed with 'br'.
dbug: Microsoft.AspNetCore.ResponseCaching.ResponseCachingMiddleware[11]
Response is not cacheable because it does not contain the 'public' cache directive.
As ResponseCachingMiddleware requires public directive for Cache-Control header the fix seems to be changing:
context.Response.Headers[HeaderNames.CacheControl] = "max-age=31536000,immutable";
to
context.Response.Headers[HeaderNames.CacheControl] = "public,max-age=31536000,immutable";
Which pushed response timing to sub ms.
I guess the question is whether we want to introduce this change behavior behind some configuration flag; as it changes semantics where assets can be cached.
Although I'd expect public to be fine as this package is for bundling static resources; so I am assuming those resources are meant for anonymous access (no secrets within) and there's cache busting mechanism to deal with versioning.
Hi,
I've played with this package over weekend and I've spot some improvements that can be done in area of efficient content serving.
So I've started analyzing whether this package supports my use case, which is basically just serving assets and adding cache busting query tag to generated links - which seemed to be working fine.
While I am focused on performance in production environment I've applied standard techniques:
In general this should boost performance, however it was not the case with this package; after closer inspection (turning log level to trace) I was getting following log lines:
info: WebOptimizer.AssetBuilder[1001] Responding from memory cache for '/js/bundle.js' trce: Microsoft.AspNetCore.ResponseCompression.ResponseCompressionProvider[6] Response compression is available for this Content-Type. dbug: Microsoft.AspNetCore.ResponseCompression.ResponseCompressionProvider[8] The response will be compressed with 'br'. dbug: Microsoft.AspNetCore.ResponseCaching.ResponseCachingMiddleware[11] Response is not cacheable because it does not contain the 'public' cache directive.
As ResponseCachingMiddleware requires public directive for Cache-Control header the fix seems to be changing: context.Response.Headers[HeaderNames.CacheControl] = "max-age=31536000,immutable"; to context.Response.Headers[HeaderNames.CacheControl] = "public,max-age=31536000,immutable";
Which pushed response timing to sub ms.
I guess the question is whether we want to introduce this change behavior behind some configuration flag; as it changes semantics where assets can be cached.
Although I'd expect public to be fine as this package is for bundling static resources; so I am assuming those resources are meant for anonymous access (no secrets within) and there's cache busting mechanism to deal with versioning.