(3)CacheKey:{https://a.example,https://a.example,https://x.example/doge.png}现在用户返回到https://a.example，但是这个time图像(https://x.example/doge.png)嵌入到iframe中。这种情况下图片缓存的key和主页面直接加载的图片的缓存key是一样的，所以可以使用之前缓存的图片资源。(4)CacheKey:{https://a.example,https://c.example,https://x.example/doge.png}本例中图片在https://的iframe中c.example，在这种情况下，图像是从网络下载的，因为在缓存中找不到相同的密钥。(5)CacheKey:{https://a.example,https://c.example,https://x.example/doge.png}如果域包含子域或端口号怎么办？用户访问https://subdomain.a.example，其中嵌入的iframe(https://c.example:8080)请求图像。由于密钥是基于scheme://eTLD+1创建的，因此忽略了子域和端口号。所以这次发生了缓存命中。(6)CacheKey:{https://a.example,https://c.example,https://x.example/doge.png}iframe嵌套多次怎么办？用户访问https://a.example，里面嵌入了一个iframe（https://b.example），里面嵌入了另一个iframe（https://c.example），最终请求的是图片。发生缓存命中是因为密钥是从位于https://a.example的加载资源的顶层框架和直接框架(https://c.example)中获取的。对现有站点的影响这不是重大更改，但可能会影响某些网页的性能。
