Response times increased after recent changes

[proxyjohn]

As discussed on official discord, response times may have been increased on libraries like picocss and others.
Previously: 30-50ms
Now: 120-150ms

Relevant headers seen are:

cache-control: no-transform, public, s-maxage=30672000, max-age=30672000, immutable
cf-cache-status: BYPASS
cf-cdnjs-via: cfworker/r2
cf-ray: redacted-BOM
cross-origin-resource-policy: cross-origin
server-timing: cfExtPri
strict-transport-security: max-age=15780000
timing-allow-origin: *
vary: Accept-Encoding
x-cdnjs-cache: HIT
x-content-type-options: nosniff

I'm not certain this is an issue with cdnjs itself. Previously, requests were being served from the MAA, whereas they are now being served from BOM. This could very well be related to my ISP or routing changes.
(For context, BOM is closer to my location than MAA)

However, since internal changes to cdnjs were mentioned on Discord, I was asked to open this issue for tracking purposes. Thank you.

[MattIPv4]

Looking at the external monitoring we run against the CDN, I don't see an obvious increase in the response times over the last 30 days:

That being said, the headers do seem a bit odd. @simonabadoiu do you have more context on what the x-cdnjs-cache header is vs. the regular cf-cache-status?

[proxyjohn]

@MattIPv4 Now I'm pretty sure that it's not cdnjs and instead Reliance Jio is throttling something
few hours ago i had leaflet library failures on specificially Reliance Jio users

I received two ecom. orders from Jio users, and i tracked that they couldn't load the map due to timed out (or something else i don't have enough log information but it didn't load), and it doesn't seem to be a downtime since both of those orders were in gap of 2 hours.

Coordinating back to the user after shifting to jsdelivr, maps worked.

You can close this issue since it's ISP level throttling and nothing can be done on cloudflare's end.
Thank You.

[simonabadoiu]

Hi ,

@MattIPv4 , thanks for pulling the monitoring 🙏

Quick answer on the headers: cf-cache-status will always be BYPASS for cdnjs now, it reflects an outer stage we intentionally bypass. The real cache state is x-cdnjs-cache (HIT / MISS / UNKNOWN), and cf-cdnjs-via shows the origin path used on a miss (e.g. cfworker/r2), so, @proxyjohn, your trace (BYPASS + x-cdnjs-cache: HIT) shows the resource is served from cache.

Given our monitoring shows no aggregate regression and @proxyjohn tracked it back to their ISP, closing this. Thanks both!