[split] WPT not detecting CDN being used

i verify that in your list you have CDN hosts for onapp. But in our case we use Onapp CDN but with our own domain since Onapp allow us to do this. In this case the CNAME is different. How may we proceed in this case?

There is any chance to force a CDN check in ‘script’ section? What do you suggest?


Do you have a link to a test result where the CDN was used but not detected? I may be able to use server response headers as a fallback for onapp or there may be something else in the cname chain useful.

Yes. You can check a result at http://www.webpagetest.org/result/131030_4A_f344d6053a1af00bd8d30fb6214c0e9b/

we did the test for staging.noticias… but the CDN is configured for cdn.noticiasao… that’s used to serve static content of ‘staging’.

The domain resolves to something.cloudhs.com, which doesn’t appear to be in the CDN list. Cloudhs.com probably belongs to Webhs.com, which I assume to be your web host? Is this a resold CDN service? Ultimately, I seem to end up at CDN.net.

Yep, looks to be a CDN for sure. A lot of the response headers look like what I’d expect to see but doesn’t let me identify it uniquely:

X-Cache: HIT from Backend
X-Age: 604
X-Edge-Location: Sao Paulo, BR
X-Cache: HIT

Do you know if cloudhs.com is CDN.net? Worst-case I can add a generic CDN fallback for the headers above so that it detects them as an unknown CDN.

cloudhs.com is the domain we use with onapp CDN system. Onapp allow their customers to configure their own domain to work with their .worldssl.net CDN system. Can you add this *.cloudhs.com to your list? The headers above i believe is not a good solution since we use different PoP’s in our CDN from different locations. The common info is our domain *.cloudhs.com

Thanks in advance and sorry for the delay answering you last contact.

The header detection is working fine now for the generic CDN fallback. It looks like you have some resources still being served directly from the staging host though so it is still failing: http://www.webpagetest.org/result/131105_X2_6a7b9d35850b6d823b3af8aadffd4b6d/1/performance_optimization/#use_of_cdn

Previously all of the CDN assets were also not detected to that is fixed: http://www.webpagetest.org/result/131030_4A_f344d6053a1af00bd8d30fb6214c0e9b/1/performance_optimization/#use_of_cdn