Any idea what would make a stylesheet(s) load images multiple times? The images are the same URL, nothing fancy going on.
EDIT: Only happens in safari (5.0.3) in both iPhone "mode" and default "mode" - i cannot reproduce the problem in FF or IE.
Apache_access_log says that the image is indeed being accessed multiple times.
When adding styles that call the image back in one-by-one, they don't seem to follow any pattern as to when they will start to double up.
I also tried making the image significantly smaller to see if it was a cache issue. Didn't change anything.
Not sure what the deal is with Safari, but apparently:
If the CSS rules that reference the same sprite-sheet are not grouped together, it will request the image more than once. (Although not the full number of times the call appears).
#divOne, #divTwo, #divThree {
background-image: url('IMGURLHERE');
}
This would request the image one time.
#divOne {
background-image: url('IMGURLHERE');
}
#divTwo {
background-image: url('IMGURLHERE');
}
This would request the image twice.
No idea as to why this happens.
Related
I am using variables in CSS/SCSS. I want to set a background (using an SVG file), but it is re-loading every time I navigate or perform some other action.
My -Variables.scss file:
:root {
--backgroundTheme: url('triangle-dark.svg') no-repeat;
}
$variables: (
--backgroundTheme: var(--backgroundTheme)
);
My styles.scss file:
#import "~assets/_variable";
body:before {
background-size: cover;
background: var(--backgroundTheme);
}
How can I avoid multiple times loading of this file?
PS: This is an Angular 8 project.
I had the same problem recently. It was caused by the inspector - "Disable cache" was enabled:
You just need to uncheck it and it will stop making new requests.
To use the image multiple times in the DOM with only one request from the CSS you should use the content property of your pseudo element target to render the image:
body::before {
content: var(--backgroundTheme, 'alt text');
}
Although you'll probably need another approach in handling the image. It might not work for you.
I have two possible idea, not sure if they works for you but it's an easy check:
If you can, don't use css variables, use scss instead. My general approach is to have a settings.scss file and import it whenever needed in the other files. It's a personal preference, I find it easier to manage like that.
It could as well be something wrong in the backend, are the caching headers set right? You can check that in Chrome itself, by clicking on tringle-dark.svg, Headers tab, then Response Headers.
I'm currently developing a complex print style sheet which is in some ways different from the HTML currently displayed on screen. I've hit a hurdle with a balance between performance and achieving the desired layout.
Basically there is a gallery of images which are loaded via javascript on the fly. Images are built dynamically via JS and output to the DOM on each request for the next image.
My problem lies in that I need to build this for printing purposes. I think I'm left with a scenario where I will have to build additional html on the page just for the print page to look correct; that isn't so much of a problem, except the images are rather big, and even using "display:none" and media print { display:block; } won't prevent the images from being downloaded on desktop devices behind the scenes by the browser. In essence I need them to stay dormont on screens, and come to life using print styles.
I had considered using the css background-image property - which I believe doesn't cause the image to load in the browser, however background image doesn't seem to reliably print across different browsers.
I've also tried using onbeforeprint javascript, but again, this is mess of browser inconsistency.
Can anyone suggest any sort of solution for this? at the moment it seems like I'm going to have to suck up the additional overhead of all the images to achieve reliable results.
If background images are an option, you could prevent the download of those when setting the parent element of the image container to display: none
Example HTML:
<div class="invisible">
<div class="img-container">
</div>
</div>
Related CSS:
.invisible {
display: none;
}
.img-container {
background: url(img.xyz);
}
#media print {
.invisible {
display: block;
}
}
Apart from that a similar question had been asked: Prevent images from loading
May be that will help you, if background images are definitely NOT an option.
I've come to believe that there's two things happening. Firstly, if you want to preload a url, you can do this:
body:after{
content: url(http://www.example.com/img/img_1.png) display:none;
}
But as far as I know, this doesn't help in this case:
body:after{
content: url(../img/img_1.png) display:none;
}
In this latter case, the image is already local, so it doesn't have to "download" it? Is that true? Or will the first bit of code cache the image even more?
I ask, because even though I do this, and I then transition to another page, using jquery mobile, the next page still takes a few seconds to load the background image. Even though it's a local asset.
How do I get around this?
From the tests I've done, it seems that two things can cause a delay when loading an image:
When the image needs to be loaded from a URL, or
When the image is locally located, but needs to be placed on the display screen
What i didn't realise is that with PhoneGap, even with the images local, it might take a little while to load. This is what was causing issues for me. Well, this and the fact that I was loading from URLs. So in my case I used the "CSS3 Caching Plugin" like so:
jQuery(function($) {
$.preload.images(document)
});
This solved my problem of loading images that was in the CSS file. But then for my own convenience, I added a section to the css file for locally cached files. Like so:
#cacheMe1 { background: #ffffff url('../img/img1.png') 50% 50% repeat-x; }
#cacheMe2 { background: #ffffff url('../img/img2.png') 50% 50% repeat-x; }
#cacheMe3 { background: #ffffff url('../img/img3.png') 50% 50% repeat-x; }
#cacheMe4 { background: #ffffff url('../img/img4.png') 50% 50% repeat-x; }
etc
This solved caching for most images, plus it allowed me to still keep URLs as loading in the app (i have a gallery section where its currently acceptable to see the images load, rather than on display).
What I also did that seems to be working, is that I use the "InAppBrowser" plugin to preload entire pages by opening them in a hidden window:
var ref = window.open('http://www.example.com', '_blank', 'hidden=yes');
If you open a bunch of files on load of the app, it seems when you either open these URLs again, or switch to the window with:
ref.show();
So there's two decent ways I've found to cache files that works perfectly for my scenario. Hope it helps someone else!
I do not know if I understood well, but maybe it can useful for you:
<img src="my.png" onerror="this.src = 'image-not-found.png';" />
When I was facing problems with preloading images I had to abandon an idea of using display:none; cause it didn't work properly (as long as I remember the browser refuses to load content of invisible elements in order to speed page load up and reducing the traffic). Instead I created a div that in browser's opinion was visible, but it had zero width and height. Required images I load as background-image for this block. The whole trick is that background-image property can take multiple values. The CSS will look like this:
#preload {
height: 0;
width: 0;
background-image: url(image-1.png), url(image-2.png);
}
So you don't get mess in the markup. Hope this trick will work in your case.
You don't need to attach the image to the DOM directly, therefor there is no need to use css to hide it. Use JavaScript to preload images.
var image = new Image();
image.src = "yourfile.jpg"
you can then provide a longer term solution using appcache.
I'm having a weird bug in Chrome, I'm applying the following CSS rule to an element:
#element {
background-color: #0E0F10;
background-image: url(images/the_background.jpg);
}
Now the first time I open a new page containing "#element", the background image isn't shown until I refresh the page cache with ctrl+f5.
I tried adding Pragma, Expires and Cache-control meta tags and it don't make any difference.
The only way to make the image to be shown at the first time is to put the absolute url in this way:
#element {
background-color: #0E0F10;
background-image: url(http://site.com/images/the_background.jpg);
}
Now the problem is that I can't hardcode a site url, I need to use a relative or relative to the root path.
Looking around I found a dirty trick for fixing a related bug in Chrome that coincidentally also fixs this problem: http://blog.andrewcantino.com/blog/2012/02/15/fixing-the-chrome-background-refresh-bug/
Basically when I open the page the first time, all the background images are reloaded through JavaScript and from here on it works fine.
However I would like to implement a more elegant fix or find the real cause of the problem.
I'll appreciate any advice.
try
background: #0E0F10 url('http://site.com/images/the_background.jpg');
also, be sure to add a width and a height to your selector!
use relative path in style rule solve my problem. such as image url is "http://site.com/images/the_background.jpg", and your css file url is "http://site.com/stylesheet/style.css", use "../images/the_background.jpg" instead of "/images/the_background.jpg" in your style rule.
I happened to run into the same problem just before I believe.
Since you haven't accepted any of the answers. You might want to try, what worked for me:
Instead of:
background-image: url(images/the_background.jpg);
Change it to:
background-image: url('images/the_background.jpg');
With ticks... It seems odd, but it did the trick for me. Since all of my url's also had an underscore, it might be related to this, though I am not sure.
Anyway, putting the url in quotes, should make it work.
See that this is old question. But just faced the same problem. My problem was related with z-index. Increased value for example z-index:2000; and now as if all works. Just need to check z-index for other elements
If your file structure is like this
Main Folder
css
img
index file
then type this syntax:
#element{
background-image: url(../img/example.jpg);
}
Wrtie this code your bug will be solved.
I'm using svg's as background-images for a responsive layout that recreates a complex brochure in online format.
Everything works perfectly for vector objects however if I embed images on the svg they don't appear on the background.
The strangest thing is if I check the svg on its own, the images are there, so this is kind of annoying!
Does anyone know if it has something to do with the svg configuration or something like that?
How can I solve this and still be able to use the svg as a background-image (background-size:cover rules!)?
Oh I should add that I've seen this "phenom" happen on chrome in my mac, if it's browser specific please say so!
The svg in question is this: http://nonstoptrip.limsomnium.com/img/fundoinfo1.svg
Unfortunately I'm not much of a jsfiddler so I couldn't create something to show you all.
Thanks in advance!
The images will appear if you load the svg at the document level. You can remove this element later and the images won't disappear. You can set it to load into a 1px x 1px element...
function loadSVG(svgpath){
if( /webkit/gi.test(navigator.userAgent.toLowerCase()) ){
var obj = document.createElement("object");
obj.setAttribute("type", "image/svg+xml");
obj.setAttribute("data", svgpath);
obj.setAttribute("width", "1");
obj.setAttribute("height", "1");
obj.setAttribute("style", "width: 0px; height: 0px; position: absolute;visibility : hidden");
document.getElementsByTagName("html")[0].appendChild(obj);
}
}
window.onload = function(){
loadSVG("../img/mySVG.svg");
}
The author of this technique is Dirk Weber, here are more details: http://www.eleqtriq.com/2012/01/enhancing-css-sprites-and-background-image-with-svg/
Webkit simply doesn't support this yet I'm afraid. https://bugs.webkit.org/show_bug.cgi?id=63548 is tracking this issue.
#Duopixel, using just "image/xml" for the type attribute also works (I've only tested it in chrome) and doesn't cause a "Resource interpreted as Document but transferred with MIME type image/svg+xml" error (while "image/svg+xml" does). Hope this helps get rid of that annoying error in the console you may be getting!