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.
Related
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)
I want to automatically refresh chrome immediately after an change of my less files. For some reason chrome can not even read my less file. So i always need to wait until the lessc have created my .css file. There a tools out there that are checking resources for changes and reload the page. I've even written my own: Luba Autoreload. What i annoying is the waiting time between less compiles and the extension request resources to detect changes. Chrome DevTools seems do not solve the problem as well. After mapping my style.css to a network resource i always need click inside the source in chrome to refresh for some reason (no auto reload).
I really prefer a way to immediately detect a less change and reload the browser. I can write a solution but i do not can spend all my time in stuff like these. Maybe somebody have an idea. Maybe there a solutions for Firefox ? I'm also using a prefixer, but i think i can forget it in this context.
Use LivePage extension. It supports LESS also. It also works offline and for file:// too.
EDIT:
Increase the refresh duration to 1000ms in LivePage's option page. It may help you. And don't select the option for "Entire Domain". It will monitor whole domain and will slow down your system, if you have many files in your domain. Use LivePage for the file, or files you are currently working on.
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
A mobile web site project I've been working on has been recently been analyzed by a performance consulting firm and they came back recommending that we move all of our .css file links to the BOTTOM of the HTML to accommodate issues on the iPhone where .css files can block concurrent server requests.
I've always known this to be true on most browsers when it comes to .js files--hence the common practice of putting .js file links at the bottom of one's HTML--but I've never heard this about .css files.
I have yet to get a response from the consulting firm with cited references as to this being an actual issue on Mobile Safari. Has anyone else heard of this and, if so, know of any specific references that talk about it (perhaps from Apple directly?)
This is not intended to be an answer to your question, but as a reference:
Best Practices for Speeding Up Your Web Site from Yahoo:
Put Stylesheets at the Top
While researching performance at Yahoo!, we discovered that moving
stylesheets to the document HEAD makes pages appear to be loading
faster. This is because putting stylesheets in the HEAD allows the
page to render progressively.
Their recommendation to move CSS to the bottom is unusual - would appreciate it if you could share why they found this to be a good idea.
edit: Looking at the general guidelines on apple.com, I couldn't find any particular reference to CSS inclusion applicable only to Mobile Safari. The basic, general instructions still state that you should place CSS in the <head>. See this page.
If you load up the following URL (http://waynepan.com/s/con/) on your desktop and then your mobile browser you'll observe a curious behaviour; On a desktop browser (Chrome & Firefox at least) you'll see the boxes populating from top left to bottom right (in the same order as on the source code) and on a mobile device (iPhone, iPad at least) you'll see the exact opposite occurring.
Albeit undocumented, this observation would suggest that the mobile browser reads the main html file first and then proceeds to render the page bottom-to-top thus loading latter hrefs first and working it's way up to the top.
You'll also observe that on the desktop browser up to 6 boxes are populated concurrently and on the mobile browser up to 4 are populated - this accounts for the maximum concurrent connections that are allowed by the browser in question to any one host.
Therefore, if page load and render speed is especially important in your mobile web app, take special care to order the loading of elements accordingly. I think your consultancy firm colleagues had observed a similar behaviour and wanted to force the CSS to load before all the other content - it would all render with the correct styles from the outset, giving the illusion (or user experience) that the page loads faster.
Alas, my 1 cents worth - I hope it is food for thought. :-)
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?).