woff font file request returned 404 before refetched properly

[woshibt]

As you may see in the following test: https://www.webpagetest.org/result/19022...iew_step1, the request for .woff2 font files failed with 404 in the first try. Whereas, the later retry succeeded.

However, the waterfall for the same page when browsing in browser (like Chrome) showed no 404 errors for the .woff2 font files.

Can anyone shed some light on this behavior? Is it particular to WPT?

(Our page and resources are behind Akamai. Not sure if that could be an impact?)

[pmeenan]

What later try? I see a request for a .woff (no 2) that succeeds but the .woff2 requests both fail with a 404. Those are different font files though.

[woshibt]

Sorry. I did not make myself clear. There was not retry for the same font files. You are right. The later try fetched .woff font files.

Still, I wonder why the request for .woff2 files failed? The files actually exist. Any idea? Thank you!

[pmeenan]

Maybe try purging the Akamai cache? The 404 responses have a cache-control header that makes them cacheable for a year. It's possible that the 404 is cached in Akamai (or somewhere else on the path).

[pmeenan]

Testing from the US doesn't 404 the font files so my guess is the 404 is cached in some of Akamai's edges and a global purge should clear it (or at least a URL purge for those files but a global purge may be safer): https://www.webpagetest.org/result/19030...view_step1

[pmeenan]

Eh, looks like it may have cleaned itself up. Here is from India: https://www.webpagetest.org/result/19030...view_step1