Basically efficient, low-latency caching for html and css content is over unless there's SRI for them. It makes sense to have a mini webpage delivered securely

Basically efficient, low-latency caching for html and css content is over unless there's SRI for them. It makes sense to have a mini webpage delivered securely that lists hashes for all static assets, and then serve some static assets insecurely to take advantage of CDNs as long as they don't disclose individual app actions (assets everyone sees on many pages). The downside is the balancing of risk for activity leakage based on insecure assets. Of course, some dynamic content and sensitive state needs to remain secure. The issue is that securing everything depends on whether you're willing to trust your CDNs and caches with your certs and private keys (granted, you already trust them to display the correct content.). That sort of technical risk management needs to be considered carefully if insecure assets can dramatically speed up UX (because TLS sessions take some or a lot more work... since how would the browser and backends do session caching or pipelining across infrastructures and providers that likely have multiple IPs? One connection per provider, each keeping their own cache for their HA boxes?) Maybe there needs to be an insecure HEAD or CACHE open standard to check content freshness of a secure page via crypto hash (say canonical uri, etag and last modified) to avoid building up a full TLS session to see nothing's changed?