I'm getting weird issues with ie and firefox when showing image datatypes stored in a sql server 2008 database. Before the images are finished loading/caching there are white lines that flash upwards through them. It is not how images normally load in firefox or ie, any ideas?
I'd try installing something like Fiddler so you can inspect the traffic back-and-forth, then try making a request both from-database (has issue) and from-file (no issue) and compare the raw data being transferred in both cases.
I suspect you'll find some difference - perhaps a few extra characters being written to the output stream at the start or an unset mime-type or something like that. Then all you have to do is work on making the database outputted file match up as precisely as possible with the working example you have and presumably the problem will go away.
If you can't find a difference perhaps the only difference is in the load speed and it's actually progressive images, using Fiddler once again you can simulate a slow connection speed which if it's progressive files should make it occur for the direct file downloads. If this is the case your only real option is to optimize your image delivery code as it's the delay in the serving of the file which would be causing it to be visible (Either that or just don't flush the output stream till the whole image is written - I presume the images are relatively small?).
Related
I have lost development time adjusting CSS with some - but not all - results when checking at Safari. Some results is much worst than no results in terms of productivity, thus this question. All results do show on the next day or so (based on cache refresh maybe). I see suggestions to clear cache but nothing conclusive. Is there a permanent fix to solve that? Maybe a script to clean cache again and again?
There are multiple things that might cause this: server cache, local cache even performance plugins if you use something like Wordpress.
Finding the exact cause needs more information from your side. But, even in the most extreme cases, there is one solution that you can use and it works almost every time for me: add a get parameter when including the .css file and change it when you make changes (style.css -> style.css?something=3123131, change the number every time).
You can do it in the files or you can even do it in developer tools, find the tag with the file and add the parameter manually there, the file willreload and you'll see the latest changes.
EDIT: this is a hack, use it when you can't control the cache or changes are small and it would be more time consuming to setup the system than to use this hack.
I'm implementing HTTP/2 push on my website. After having made it work, I'm bit surprised on the waterfall I get. I enabled throttling in Chrome to "Slow 3G" to see more accurately what is happening.
I'm pushing 4 assets (in that order):
home.min.css (12kB)
front_layout.css (213kB)
front_home.css (8kB)
front_layout.js (360kB)
Here is what I get during loading:
You can see that the 2 biggest files I'm pushing are "Pending". I can understand this, as even the main HTML document isn't finished loading yet. But the thing is that other non-pushed assets (the 2 images just below) are already loaded! How is it possible that a pushed asset hasn't started loading whereas non-pushed assets are finished loading?
Note that the blue part of a pushed asset is defined as "Reading Push", whereas the blue part of a old style request is defined as "Content Download". Could it be a plotting error from Chrome Inspector? Or a subtle difference between content download and reading push that I do not understand?
Let's see a bit later in the loading, it's even more surprising:
There is a strange delay between the end of the main HTML document and the start of one pushed asset. It seemed to me that a pushed asset would come right after the main response data, I don't get what this ~8 sec delay comes from. What do I miss?
At page load, here is what I get:
So:
Large pushed assets start downloading after other non-pushed assets
(last line) One large image (340kB, same as my large pushed asset) on another domain finished loading before my pushed assets (dispite being slower to download).
I get the same graph with Fast 3G. Only when I totally disable throttling (running on my own machine) I get what I expect:
I'm confused on what is going on. Is HTTP2 push a good thing in my case?
I read many articles on how http2 is working exactly but I really don't manage to understand what is happening in my case. Any insight is welcome!
Thanks a lot!
I also noticed that there is a mysterious gap between my index.html and the pushed resources. The end of the blue bar for the index.html is when the browser finishes downloading the file. Then it needs to parse the HTML, once it meets the point where it needs the pushed resource then it will start requesting for it. So I guess the gap is for the browser to parse the HTML and do some background stuff (eg. loading the HTML, allocating space...)
I'm not sure if this is the correct explanation but hope it could give you some insight (after all this time... or if you did find out the answer please share it! thx)
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
I have written a small picture script which shows a directory listing with thumbnails and also previews of the pictures.
Directory listing example
Image preview example
Source code
In some cases, when you click through several image previews (you can also use the arrow keys left/right to do that faster), some images don't fully load (and they are only shown partly then).
I think this has started to appear more often since I am preloading the next few pictures but it also has appeared before. This also occurs most often if you switch the images very fast.
I wonder why this appears and how I can avoid this. I guess that the browser somehow looses some connection to the server (or the server closes it unexpectedly for some reason). Thus I tried to work around this by setting Content-Length (and I was hoping that the browser would reconnect automatically if the file was not received fully) but that didn't helped.
Also, in the browser, a normal reload of the page doesn't help, I have to force a full reload.
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.