Is there a major performance difference between the following:
<iframe style="visibility:hidden" />
<iframe style="width:0px; height:0px; border:0px" />
I'm using a hidden iframe to pull down and parse some information from an external server. If the iframe actually attempts to render the page, this may suck up a lot of CPU cycles. Of course, I'd ideally just want to get the raw markup - for example, if I could prevent the iframe from loading img tags, that would be perfect.
I think either way your iframe is going to load it's contents. You can do a simple test by hiding and then showing the iframe with a page that takes a while to load.
If the iframe (when made visible) immediately shows the long loading page, you'll know it was already loaded in before the show.
If you're using FireBug then you can use that to look at the HTTP requests made. This will show you whether there's a HTTP request made by the iframe.
As far as performance differences, I doubt there's any between the two pieces of HTML you posted. If anything I'd say that setting visibility to hidden will be more "efficient" since the browser doesn't have to wory about rendering anything visually, even if it is 0*0px.
Still, I don't think there's any real performance difference and especially no major performance differences.
Update:
I just tested in FireBug to see if the iframe still loads its contents when set to visibility:hidden, display:none; and with it's height and width attributes set to 0px and in all cases, the iframe contents was loaded.
Visibility:hidden will probably be more performant, as Browser doesn't have to recalculate, -layout and -paint. The element will just not be drawn at all, without even checking it's layout.
Related
I'm working on a site where the client requested a video fill a div as the background. I have it in and working for myself but they keep complaining that they can't scroll. I have no issues on multiple computers scrolling. Is there some sort of common issue other than a slow machine that would cause this? Could it be a CSS issue? The staging site is here if it helps: http://arkroyal.staging.wpengine.com/
UPDATE
I am using a video hosting service and it seems this is only happening when the flash fallback is in there... I have set it to flash be default now and I can not scroll when my mouse is over it. So now I guess this is a flash issue?
I agree with user3285910's answer, however, that's not to say there isn't anything you can do about it.
When I first went I didn't not attempt to scroll, I just let the entire page load. Afterwards I checked the load times for the media, the Winsta MP4 took 27.36 seconds to load. That's in Chrome on a T1 line. I used Chrome because the webkit browsers are known for their laggy video lading.
With that information I would look at changing the preload value for the <video>. Currently it's "none". There are a lot of different approaches to preloading data and you cannot account for everyone's PC speed, bandwidth, etc.
I would recommend letting the browser determine their capabilities for you and adjusting accordingly. Usually 5-7 seconds of preload is enough to get around the jumping behavior. Here is a link to an article that goes into more detail with analysis.
After looking at the staging site, it doesn't seem to be an issue with the site itself, but more the video you are using. The video is high quality and will cause systems to slow down drastically. If this is the video they want as the BG, I would see if you couldn't get the video resolution lowered drastically, as this will cause issues in the rendering on some systems. This will also make users unable to scroll down the page, because their video card is busy trying to render the images that are being produced by the BG video.
Working on an image heavy website, discovered a strange bug(?) in Firefox. Any CSS background properties are rendered onto transparent png's. It occurs after the initial render, during the cache refresh. This appears as a flicker if you're using broadband but becomes extremely noticeable as you scale down bandwidth.
General progression of the issue seems to be:
Page and images rendered from cache
Firefox removes the cached images.
Firefox begins to reload images but displays a box with the CSS properties of the background.
I've recreated a (hideously colorful) example, but you may need to use fiddler, or another program with bandwidth throttling/emulation to see anything more than a flicker. Obviously, you'll also have to load once and then refresh to experience the error. And again, it's only in Firefox.
I have tried a plethora of various suggestions, none worked. Just need a fix, hacks will work as long as they don't effect other browsers.
EDIT: Here's a video so you can see it in action.
Since I cannot recreate the issue on my Firefox (10.0.2) on my computer (Win 7) with my particular hardware (which may or may not be a part of this problem), I offer the following as a guess at a solution, though one I would have assumed you tried already.
Target your img tags (preferably with some css more specific than below) that you have the issue with and try setting one of the following:
Either:
img {background-color: transparent;}
Or:
img {background-color: transparent !important;}
Update: Another Possible Workaround
Have javascript make the relevant img tags invisible to start and also bind an event to them so that when they load, they become visible again (JQuery example):
$('img').css('visibility', 'hidden'); /*not using "display" keeps layout*/
$('img').bind('load', function() {
$('img').css('visibility', 'visible');
});
I cannot test the above, so no guarantee it will work, but is another idea.
The first time I go to this page, the positioning of the slideshow (developed using the JQuery cycle plugin) is all messed up, like this:
If I then refresh the page, it displays correctly, like this:
How can I ensure that this page displays correctly the first time it's viewed? The incorrect layout seems to happen more often with Chrome than with other browsers, though as you can see from the screenshots above it also happens with other browsers.
Thanks,
Don
Add width and height attributes to the images.
I'm guessing that the JavaScript activates before the image is loaded, it then does a couple quick computations to get the dimensions it needs, and locks them in place; all of this happens before the image is loaded and since there are no width or height attributes, the dimensions come out way off. On the reload, the image comes out of the browser cache so the dimensions are known when the JavaScript runs.
Your JavaScript runs when the DOM is ready, not when every single thing has been fully resolved and loaded. You could also try binding your slideshow to the load event rather than document.ready.
You see this in Chrome more than other browsers because Chrome is really fast and that magnifies the timing issue.
I used this method: CSS Throwdown - Preload Images without JavaScript
By Jeff Starr - http://perishablepress.com/press/2007/07/22/css-throwdown-preload-images-without-javascript/
It works fine when I view it in web browser, however on mobile, it doesn't seem to have any effect, .png icons still takes too long to load.
Preloading doesn't make everything magically faster - it just means that requests are sometimes issued before the data is required. Is the preloading happening at all? Perhaps things are just slow because the mobile connection isn't great.
That method of preloading images looks to me like it'll work fine on mobile browsers - I highly doubt mobile browsers "optimise" by not fetching images are not visible.
If the mobile browser doesn't support javascript (or support javascript well enough) then preloading that way may not work.
I expect it's also unlikley that preloading with javascript would work on any browser or proxy which uses transcoding or pre-rending on the server.
Have you tried the old school (90's) approach to preloading which was to include the image on the homepage (or even each page) but sized to 1px by 1px (could also maybe try 0x0).
This could mean that the user is paying to download more content than they need. Which is an issue to consider.
First thing to do is: make sure you really need the image; make it as small as possible (physical size & image encoding compression); and [gzip] compress the file as it's sent over HTTP. Also make sure that you're doing everything you can to allow the user/client browser to correctly cache the images.
If your site is going to be aimed at mobiles, and not just the one you are testing with, you might have difficulty in finding a universal solution that works across all mobile browsers. If you want to improve the download time of the image, maybe you could consider adjusting the compression of the image to reduce the size?
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
fb like button creates a white background on page onload in all ie versions
I have a site where portions of the content are loaded into IFrames.
The problem I'm having is that the inside content of the iFrame is white until the page itself loads, and the content has a different background color (blue, in this case). So I have these white squares on the screen until the contents load.
Is there any way to specify what color the empty IFrame should render as until it has content?
Or am I taking the wrong tack here - is there a good way to keep the page from rendering until the contents are ready to be displayed?
UPDATE: Looks like the "white area" bit I'm describing is IE-specific.
It's not too hard:
<iframe id="IFR" src="time.php" style="background-color: #f00;" />
Edit: I neglected to test in IE -- it does work in FireFox. Example at: http://beta.tagcloud.com/contain.html
The example demonstrates that the page quickly switches to all red, and then when the iframe loads (in 5 seconds), it switches to black.
This was driving me nuts, but I actually found a solution that seems to work in IE6 and 7. Haven't tested in other browsers, but Firefox seems to do it properly anyway.
The problem is solved if the iframe isn't displayed when loading, but an iframe seems to fire the "onload" immediately so after putting in an alert, I noticed it fires the onload twice, once at page load, then again once the iframe page loads so...
<iframe id="theFrame" src="frame.html" style="display:none;" onload="loadFrame();"></iframe>
//and here is the associated javascript
loadCount = 1;
function loadFrame() {
if(loadCount > 1) { //this keeps the script from displaying the frame on the first fire
document.getElementById('theFrame').style.display='';
return;
}
loadCount++;
}
You could perhaps set the iframe's document and set its style before loading your content.
Or you can use Ajax and not have these issues. =] (Assuming if it's appropriate for the task, of course.)
Simpliest way to fix this to just not show the iframe until it is ready. That way you can set whatever background you want under the iframe. You set a background and prevent showing the iframe until loaded like so:
<div style="background-color:#XXXXX">
<iframe src="..." style="visibility:hidden;" onload="this.style.visibility='visible';"></iframe>
</div>
The only downside is if your visitor has js turned off they aren't going to see the iframe. If that is a concern for you check out http://css-tricks.com/prevent-white-flash-iframe/