Is there a way to "cache" background image.
For example..
Background image is 3x3px and it's set like this:
body {
background: #000 url(bg.png);
}
When refresh happens, background image "flickers" for second.
Is there a cross-browser solution? (for Apache/PHP server if that is relevant)
If you go to seo.hr and browse navigation,... you can see what I'm trying to do.
http://www.seo.hr/
http://www.seo.hr/usluge/izrada-stranica
http://www.seo.hr/usluge/optimizacija-za-trazilice
I think you need to determine first if the issue actually is a caching issue or if it's caused by the size of your image. You could use a program like Wireshark or Fiddler to do this, but to be honest it's overkill for your need and you probably already have a browser with developer tools.
Here's how you determine where an image is coming from in Chrome (the other browsers are similar).
Open your developer tools and go to the "Network" tab.
Find "bg.png" in the list of network requests and click on it's name. Below is an example of having selected a stack overflow image from this page.
Notice that it says status 200 (from cache). The browser didn't need to go out to the server and rerequire that resource. It used the cache. If that "from cache" text wasn't there it wasn't reusing cached resources.
There is also the potential that you'll get a status code of 304. That means that the server said the image wasn't modified since the last request that you made. You do make the server trip in that case.
Ok, so my image wasn't in cache... now what?
There are a few reasons that this could occur.
You're request headers aren't set to tell the browser to cache the image (also found in that same "Headers" tab that you would have seen that Status Code if the browser actually went to the server for the image). You'll want to set cache-control and expires to something that makes sense for you. Cache headers can get a bit complicated you may want to browse through this caching tutorial document.
Is it SSL? If so not all browsers cache this but most modern browsers do. Set cache-control: public on these images (and also expires).
The real question here is how do you fix this? Unfortunately, that's entirely dependent on the server and/or the framework that you are using. As the OP is using Apache, they can find great documentation on the Apache module mod_expires to figure out how to tweak caching for their site.
Yes!
You should decide whats more suitable for you, but at this time we have some methods, like:
Pure HTML/CSS
Javascript Only
Mixed HTML/CSS/Javascript
Using base64 to encode the image somewhere on the source code
At this point I recommend a mixed solution, using javascript. This will make it work on many browsers as possible.
There is a good tutorial at:
http://perishablepress.com/press/2009/12/28/3-ways-preload-images-css-javascript-ajax/
Having several images in one can take you a step beyond that, so check this sprites article:
http://www.alistapart.com/articles/sprites/
You can try to encode your image in base64 and put it directly into CSS source code. I found a question about pros and cons over here.
Make your tiled image much much larger, when the browser engine renders the page it has to multiply each tile to cover the entire width and length of your object, which results in bad performance with small tiles on large objects.
Small tiles -> more repetitions -> slower performance
Related
Hello I am developing a website on ASP.NET and while developing it I am also testing its behavior and changes. The problem I am facing is some times when I make change on .CSS file those changes does not appear on the browser even when I refresh it or rerun the project but when I run that project on different browser it began to show those changes. If it is a code related or browser related or IDE related please let me know. Thanks
Try hitting ctrl-F5 - that will force a re-load.
Unless you change the name of the css file or other resource, the browser can cache that information for months on end.
In fact, some utilities will even add say a dummy parameter to the linked css file - thus on each build the parameter is updated - and thus the browser will not use the older cached value (but, I not found a great working and easy to use utility that does this).
The other way? Empty your browser cache. So yes, the cache can be a REALLY nasty issue during development. And in fact it can be REALLY nasty when you update your site - users will not see say a modify css file, since it been cached, and with the same name, then users will not see new fixes/style changes or even even things like text alignment that you fixed in the css file.
As noted, in most cases, if you launch a page, then try hitting Ctrl-F5 (I think this works in most browsers). If that fails, then you have to in the browser re-set the cache (empty the cache), and then you see the new changes.
I wish had a better solution, and I wish one could just say:
Ok, please re-set ONE time for all past users - since they will often not see your changes - and you don't have much control with any real great ease to re-set the cached information. There are truck-loads, book sized articles in dealing with this issue, but sadly, there not really a great solution right now. If you want say things like cached css stuff to go away client side? Then you have to change the name of the css file - and that can be painful.
At least during development? Well, let the page load, then try Ctrl-f5 - that works well in most cases.
I Tried to find the answers here on stackoverflow but couldent find it , so I hope someone can help me.
The question is pretty simple I guess, Im trying to optimize My site with a image sprite instead of many images.
And I wanted to know if a background:inherit counts as HTTP Request?
Was thinking otherwise I could let My DIVs just inherit the first DIVs background image and save me a lot of Requests.
And do Two img links too the same image sprite count as one or Two HTTP Request? I mean do the browser understand that it already download it?
Assuming that you cache images, two (or a thousand) image links will only issue one HTTP Request, as long as the image itself doesn't change, though it's really about the browser implementation. The same goes about using inheritance or even using the same resource in different CSS elements. If you are using Chrome, I'd suggest that you'll take a look at the network tab in the Developer tools and verify that this is indeed the case. Otherwise, you can try using Fiddler.
If you'll share a link, I'd be more than happy to take a look at it myself.
I'm asking if you know if there is a ready-made solution, not really how to do it.
I'm quite sure I can pull it off myself, even if I never ever touched the bytes of a JPEG manually. If you'd like a crack on it, you're invited to do so ;)
The basic Idea is that you have a site with a few JPEG images, but you want to reduce load as much as possible for mobile users.
So you ensure that all of your JPEG´s are progressive and only sends the low-frequency bits of it first, idles down the TCP-connection, and waits for the client to report in how big the available space is in the browser window.
Or alternatively, you have some sort of browsercaps.ini or similar, and rely on that to get the initial resolution -- and then have the reporter report a correction if necessary.
I actually needs this for two entirely separate environments, one is using PHP and the other is using node.js (The latter one is of more importance).
I'm quite sure picasaweb is doing this stuff already, or at least did. You could view an image, and it loads progressively -- then you could enlarge it, it got blocky but continued to load in progressively, I remember that I was quite impressed by that!
(And its unfair that Google keep the cool stuff for them selves, remember their motto {°«°] )
Why not send the client a list of images that could be used for a specific img tag, then have the client determine which one it should use?
It is possible to determine the screen size of the device document.write(screen.width+'x'+screen.height);or the size of the browser. And instead of adding a src attribute for each image, adding the possible sources to a html5 data- attribute like so:
<img data-img="mobile:some-img.jpg,desktop:other-img.jpg" />
JavaScript (With jQuery):
$('img').each(function(){
$(this).attr('src', $(this).attr('data-img').split(',')[0].split(':')[1]);
});
A site I am working on just exceeded the monthly bandwidth our host provides (25,000 MB) and when looking at the server stats and logs, I found TwinHelix's iepngfix.htc to be the #4 largest bandwidth drain. #4 hits:73939 KBytes:181035 /iepngfix.htc
I find this especially interesting because a .swf used as a background image on every page had only 3,918 hits compared to the 73,939 hits that iepngfix.htc received. Hard for me to believe that there are even that many IE6 users visiting this site.
This file is being called within screen.css in the following way:
img, div, input { behavior: url("iepngfix.htc") }
The only way I can explain this 4KB file eating so much bandwidth, is if it is being read and re-read for every single img, div, and input element, whether or not there is a PNG used and possibly for more browsers than just IE.
Am I understanding this correctly?
If anyone could help me understand how all this works, it would be much appreciated. Thanks!
It could be that caching is not properly set up for the .htc file extension in your web server. Check the response headers, e.g. using Firebug, for what caching instructions get served.
Also using Firebug's "Net" tab, you'll be able to see whether the URL gets loaded in non-IE browsers. It shouldn't, but you never know.
I wonder why no browser out there has such simple but essential feature. Am I missing something? Is there a technical reason?
I'm tired of all those javascript/flash/java hacks out there ...
There is no technical reason preventing the browser from calculating the total bytes to be sent and then tracking how many have been received by the server (Thanks, Kibbee for your comment). Firefox had a functional upload progress indicator until version 0.9, but that build broke it in 2004.
Reading through the Bugzilla updates, it seems that this feature doesn't seem to benefit enough users to get any traction from the developers.
Users who regularly upload very large files tend to use tools like FTP that are designed for this purpose, so they are not affected.
Adding to flamingLogos argument, you might operate behind a proxy which takes your five megabytes of pure goodness within a second, and then sends it off to the server over a 56kbit modem.
I perceive a wrong progress bar slightly worse than no progress bar at all, and there would be many people for who it would be wrong all of the time.
Yes, it's silly, and for some reason browser makers are ignoring it.
I would strongly dispute that large file users use FTP - hardly anyone knows about that anymore and all the common Web apps require HTTP uploads for video, audio and pictures (e.g. youtube).
Ironic that user participation and media is the key to Web 2.0, yet the main mechanism for user participation is so poorly handled by browsers.
For Firefox there have been bugs languishing for years, such as for a better upload progress display:
https://bugzilla.mozilla.org/show_bug.cgi?id=243468
Get voting! :)
The existing progress bar in the status bar is broken for years - see bug 249338 - and it will let you silently abort an upload - see bug 432768.
If you are using Firefox, you can use the new UploadProgress add-on https://addons.mozilla.org/en-US/firefox/addon/221510/ designed for this purpose, that is displaying the progress of your uploads and an estimated remaining time.
You have to post back to upload a file, regardless of whether or not you are being "sneaky" about it (using hidden iframes, for example); the browser's own progress bar (usually down in the status bar) is the file upload progress bar in that sense, although not exactly.
It's just that you can't easily use that data for yourself, so you have to approximate it with a lot of client-to-server communication tricks.
There's no real technical reason you couldn't have a reasonable progress indicator as you do with downloads. You should suggest it as a feature request to your favorite browser.
That said, I think the main reason there are so many javascript/flash/ajax-based upload components isn't so much to provide progress bars (though that's a nice bonus). It's usually because they want to provide a better UI for selecting the data to be uploaded and to sometimes manipulate the data before uploading. The basic file upload feature that's in the HTML specs results in the "Browse..." button that pops up a file open dialog and uploads the raw file data as is to the server.
Chrome has an upload bar that shows the % of loading.
Or, like Peuchele says, there's also an Addon for Firefox.
The web browser has always been that, a browser of the web. It is a mechanism for consumption. Our ability to upload information through the same portal is somewhat of a hack.