I am trying to speed up load times on a Portal. I have a story map with an embedded web app that loads a web map. Watching in my browser's dev tools, there are over 300 requests, and many of those are for stock .js and .css files, which I assume only change when ArcGIS is upgraded. The initial performance is slow, but it would be a big win if subsequent loads were faster. Unfortunately, ALL those resources are requested all over again every time I load my story map. I see two semi-related issues:
Expiration: Looking at a stock JavaScript file download, the Expires header comes back as already expired:
Expires: Thu, 01 Jan 1970 00:00:00 GMT
My understanding is that the browser will re-request this file each time since this is marked as expired. Is there some way to get the server to return a future date for the Expires header? I'm not sure if this is in the bowels of Portal or something we can set in IIS.
Last-Modified and ETag headers: The server returns valid looking Last-Modified and ETag headers with these resources. Here is a sample of these headers returns from a stock JavaScript file:
Last-Modified: Mon, 15 Jun 2020 20:34:56 GMT
ETag: W/"917504-1592253296000"
My browser correctly submits those in subsequent requests (note: by convention Last-Modified becomes If-Modified-Since and ETag becomes If-None-Match). If those come in the request headers, the server should reply with an HTTP 304 code (Not Modified) with no data in the response payload, signaling that the browser already has the latest resource. The web server is ignoring these, so I am getting all HTTP code 200 responses with all the data returned.
Figuring out the expiration (above) would make this a moot point if it could prevent the browser from making unnecessary requests. But failing that, is there a way to get the web server to honor the Last-Modified and ETag? This still requires a round trip to the server, but at least the server can reply with a zero-byte payload.
