Expand my Community achievements bar.

SOLVED

Timing of the Build Success Message & Embed Code Updated

Avatar

Level 10

In the West Coast Office Hours on 8/15, I believe I heard in the recording a statement like this "The success message won't be shown until your deploy/build is actually published"

When I do a Build to Stage, I get the green circle (denoting the build was successfully) and then almost 2 minutes later, the change will show up in my embed code.

Now, I know 2 minutes is pretty speedy...I was under the impression, though, with the statement in the Office Hours that the timing of the message being shown was a big deal for the Launch team so I expected the message and the embed code to be more in sync. Or maybe I misunderstood the statement.

Thanks -

Sarah

1 Accepted Solution

Avatar

Correct answer by
Employee

It has to do with a delay on the Akamai side between when we upload a new file to their Origin, and when that new file is then pushed out to their edge servers, specifically the edge server that is geographically closest to you when you visit the webpage.

So the status indicator is the best we can do, which says that the file has been pushed to Akamai's origin.  When we do that, we make a request to Akamai to flush their cache so that the latest version goes out to their edge servers, but there is a delay there.  And right now, it can have a fairly wide time delay from <1 minute to +30.

We actually have one of our developers working on an upgrade to use a new version of Akamai's purge API.  If this performs as promised these delays should all go to <10 seconds.

Update 2017-11-27: We are now using the new version of Akamai's purge API.  The other factor in here is browser cache (how long the browser you're using is actually holding onto a cached version before it actually makes a network request to retrieve a new version).  For testing purposes, you can clear your browser cache or open an Incognito window.

For the end users, we have some additional changes coming in Q1 2018 to have Akamai set cache control to 0 for Development and Staging libraries and to set cache control to 1 hour for Production libraries.  Individual browsers may not respect the cache control settings, but that we're doing what we can.

View solution in original post

1 Reply

Avatar

Correct answer by
Employee

It has to do with a delay on the Akamai side between when we upload a new file to their Origin, and when that new file is then pushed out to their edge servers, specifically the edge server that is geographically closest to you when you visit the webpage.

So the status indicator is the best we can do, which says that the file has been pushed to Akamai's origin.  When we do that, we make a request to Akamai to flush their cache so that the latest version goes out to their edge servers, but there is a delay there.  And right now, it can have a fairly wide time delay from <1 minute to +30.

We actually have one of our developers working on an upgrade to use a new version of Akamai's purge API.  If this performs as promised these delays should all go to <10 seconds.

Update 2017-11-27: We are now using the new version of Akamai's purge API.  The other factor in here is browser cache (how long the browser you're using is actually holding onto a cached version before it actually makes a network request to retrieve a new version).  For testing purposes, you can clear your browser cache or open an Incognito window.

For the end users, we have some additional changes coming in Q1 2018 to have Akamai set cache control to 0 for Development and Staging libraries and to set cache control to 1 hour for Production libraries.  Individual browsers may not respect the cache control settings, but that we're doing what we can.