UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.94 Safari/537.36 Example URL: http://drifted.in/other/svg/css-test-case/ Steps to reproduce the problem: There are 10 SVG images inserted using both <object> and <img> tags in http://drifted.in/other/svg/css-test-case/ What is the expected behavior? Only the first object is loaded directly, the rest from cache, like these inserted using <img> tag. What went wrong? All 10 images inserted using <object> tag are loaded directly. Does it occur on multiple sites: Yes Is it a problem with a plugin? No Did this work before? N/A Does this work in other browsers? No Firefox, IE, Edge Chrome version: 62.0.3202.94 Channel: stable OS Version: 10.0 Flash Version: I am going to report this issue to all browsers. Not sure why SVG images inserted as objects are not cached like <img> or even <iframe> tags. It would improve loading of specific pages significantly. Moreover, if those objects share some resources, e.g. fonts, they are not cached as well which makes loading the content even worse (as can be seen on test URL).
Nov 30 2017,
Nov 30 2017,
Tested the issue on chrome reported version 62.0.3202.94 using windows 7 by following below steps: 1. Clear cache history 2. Navigate to the link http://drifted.in/other/svg/css-test-case/ 3. Observed SVG as IMG is loaded first then SVG as Object please find the attached screen-cast and if possible could you please provide the actual issue showing screencast and also let us know if we have missed any steps in reproducing the issue
Dec 1 2017,
I am attaching screenshot from Dev Tools. You can see open-sans.svg is loaded 11x, once as svg+xml type (= <img> tag) and 10x as document type (= <object> tag), hightlighted in red rectangle. It is IMHO wasting resources as <object> content could be loaded 9x from cache. In the orange rectangle you can also see repetitive loading the same font, which can lead also to excessive data traffic.
Jun 18 2018,
We're getting hit by what's probably the same issue in a slightly different way. If you take the OP's sample code, and programmatically modify one of the <object> tag's data attributes, even setting it to the same SVG "open-sans.svg", then you'll see the request hit the network tab. It will get served by disk cache, unlike what happens to the OP during the initial load, but that delay is enough that the user sees a visible flash in the affected image. For SVG included by <img> tag, nothing hits the network tab when the src attribute is changed, and the DOM elements don't jump at all. So apparently, there is NO caching of SVG for <object> tags, so that setting the data tag to itself or back and forth between two values, will result in a network tab request every time, whereas <img> tag SVG appears to be cached deep inside the browser so it can be served very quickly as DOM elements are created, resulting in no visible flash. Seems like a solution to the OP's problem should attempt to address mine as well - so that you won't see any network tab activity from toggling an <object> tag's data attribute back and forth between two files (for example). Fixing this from our layer (JS) would be extraordinarily complicated, as we'd have to create off-screen pools of objects, created speculatively, and then use them to dynamically update placeholder HTML.
You disabled disk cache in the DevTool. Without such special debug feature, Chrome loads svg resources from disk cache for object tag. image load is still using memory cache even if the disk cache is disabled. This is implementation details, and the first request still goes to the network due to the disabled cache order. So why object tag does not use memory cache? Chrome uses DocumentLoader to load svg image for the object tag. This is to provide DOM access into the content. E.g., you can still access to the loaded content like document.getElementsByTagName('object').getSVGDocument().getElementsByTagName('text').textContent = "Content is also Open!"; So, each instance needs not to be identical. The first object modification should be isolated from other object contents. Technically said, memory cache is just a C++ level object instance pool to be shared from multiple HTML elements. So, it can not handle such mutable instance directly. But SVG instance also can handle the DOM tree from the loaded content. So, technically memory caching would be possible, but I'm not sure details because I'm not an expert in this area. Add SVG label to the components. Remove OS labels, since this is shared among all platforms. CC hiroshige who are an image loading expert. But probably, this is not high-priority issue. So I'd put P3 for this bug.
One typo: > But SVG instance also can handle the DOM tree from the loaded content. But SVG instance also can handle the DOM tree *separately* from the loaded content.
Sign in to add a comment