Develop Reference

How can I break a third party iframe on my site, with code?

I am not a programmer.
Someone has scraped my site home page source code and placed their iframe over it, so that when the page is fetched it displays their content.
The iframe is not immediately apparent but it's there, just well hidden. These sites are all hosted on hacked servers running WordPress. They still display our site links and architecture that is being delivered by our server. There are currently over 160 such sites built using the same method.
I believe that they have disabled js so that may not be an option.
I know that we can break out of an iframe if it's our site in the frame.
Is there any way, either on the server side or on the page to break their iframe and force our page to the top?
If we can break it, then our code becomes worthless and with a bit of luck they may stop using it.
Update:
Just wanted to add a few points to anyone who has any ideas.
1, They already have the code, only things being served are the images and CSS files because they have only left those links in the page.
2, They are showing their site by floating it with a z-index on top of everything, which is why when you view src you see the site above and not the site that is floated in the iframe.
3, The iframe is visible if you inspect element with firefox and scroll to the top of the page you can see the iframe they are using.

Based upon the additions (currently in an answer), since they have your code there's not much you can do about breaking out of the iframe.
Depending upon your server environment you could try determining what page is requesting your images and CSS, and then display modified versions to those accessing the scraped versions. The key word for your searches is 'hotlinking.'
Possible modifications could include not serving the assets (images/CSS), or returning a CSS file that just does a display:none; on HTML elements to hide.
It might be a fool's errand, but trying to contact the hosts of the hacked servers might be a good idea, but I can't honestly say that it will get you very far, and might be a waste of time for the majority of them.

Flashing between page loads

On a website, I'm experiencing a "flash" of white that occurs between page loads. It looks bad because I'm using a background image and when the page loads, the background images flash before it comes onto the screen (take a look for yourself). This issues occurs in chrome and IE but not in firefox.
The site has a way of preloading stuff. Every element on the page is in a div wrapper #website which is initially at display:none, and every image is in a div wrapper #website-images which is also hidden. Then the site (using a jquery plugin) checks to see if all the images in #website-images are done loading, once they are a cookie is set to remember that this user has loaded the images already so it won't go through the preloading process once they go to another page or reload the current one, then a call to $("#website").show() is made to display the webpage.
So what could be causing this flickering between the page loads? Is it my way of preloading images? I've added different doctypes, and changed meta information but NOTHING has worked. I'm really lost here, does anyone have any ideas or insights?

This is happening because the DOMLoaded event is fired enough milliseconds before the page actually renders.
In a nutshell, this means you have to optimise your website's speed. This doesn't mean to make it download faster, but it means to download in the correct order, in a non-blocking way.
Step one: Your markup
1)
It seems there is a lot you can do to optimise your markup. Firstly, the order of stylesheets and JavaScripts can be optimised. To ensure CSS files are downloaded asynchronously, you always have to include external CSS before external JavaScript files. style.css is downloaded after some/all of your JavaScript calls.
There is 1 script block found in the head between an external CSS file and another resource. To allow parallel downloading, move the inline script before the external CSS file, or after the next resource.
2)
Your main JavaScript file is inline within your markup. Not only does this block the page download until the script has finished downloading, but having it before your content is probably causing (or adding to) the white flash.
Loading your script asynchronously in the head is my preferred method. You will then have to trigger your script when the DOM has finished loading, or you can achieve the same result by placing the script at the bottom of the body tag.
Step two: Harness the browser's capabilities
1) Looking at the http headers, there are 28 items being served as separate HTTP calls, that are not being cached on the browser (including the html pages, jpg images, stylesheets and JavaScript files).
These items are explicitly non-cacheable, and this can be easily fixed by editing your webserver's configuration.
2) Enable gzip compression. Most web browsers (yes, even IE) supports gzip decompression, and most (if not all) web servers support compressing using gzip. You could even go overkill and look into SPDY, which is an alternative lighter HTTP protocol (supported in Chrome and Firefox).
Step three: Content serving
There are around 30 individual items being served from your domain. Firstly, consider how you could reduce this number of requests. 30 HTTP requests per page view is a lot. You can combat this using the following methods:
1) Paralleled downloads across multiple hostnames. Browsers currently limit the number of concurrent connections to a single domain. Serving your images from a separate domain (for example, img.bigtim.ca) can allow them to be served in parallel to other content.
2) Combine multiple items into one. Many items that are downloaded are purely style content, such as the logo, menu elements, etc. These can be combined into a single image (downloaded only once), and split using CSS. This is called CSS spriting. Stack Overflow does this: look here.
3) If you cannot reduce the amount of items needing downloading, you could reduce the load on your server (and in turn, the client's browser) by serving static content from a cookieless domain. Stack Overflow does this with all their static content such as images, stylesheets and scripts.
Step four: Optimise your own code
There's only so much that HTTP and browser technology can do to help your website's speed. This last step is down to you.
1) Is there any reason you choose to host jquery yourself? Jquery's download page shows multiple CDNs where you can point to for speedy, cached script downloading.
2) There are currently over 20 unused CSS rules within your stylesheets (that's 36% of your entire CSS file). Have a re-think of what is really needed.
3) The main chunk of JavaScript (at the top of your body tag) seems to be a hack to attempt to speed things up, but is probably not helping anything.
A cookie is being set to specify whether or not the page has faded in yet. Not only are you using JavaScript to perform a transition which can happily be performed by CSS, but more than half of the script is used to define the functionality for reading and writing the cookie.
Seeing things like this: $("body").css ("background-image", "url('images/background.png')"); and $("#website").show (); usually gets me ranting about "separation of concerns", but this answer is long enough now so hopefully you can see that it is bad practice to mix style and functionality in the same code.
Addendum: Looking at the code, there is no need for jquery at all to
perform what you are doing. But then again, there is no need to
perform what you are doing, so you could probably do better without any
JavaScript at all.

Move your javascript to the end of the html just before closing the body tags. Sometimes it helps.

I know this is old thread but here is a hack I tried and works.
The idea is not to display anything while CSS is loaded completely.
in html file:
<body style="display:none">
in your CSS, the last line:
body{display:block !important}

CSS is render-blocking.
Divide you CSS into 2 parts -
Critical CSS
Non-Critical CSS
Make Critical CSS load with the page. It should come embedded within the head tag.
Make Non-critical CSS lazy load via ajax.
This will result in serious performance optimization in your webpage leading to less white-screen time.
Also, you can consider loading your Javascript in async/defer way.

Forcing external javascript files (from Digg, Reddit) to load last

I'm working on a WordPress site that has two external javascript files load about half-way down the page. The files are badges from Reddit and Digg, and often add about 4-8 seconds to the total loading time of page — while also preventing the bottom 50% of the page from loading too.
The Digg and Reddit javascripts render an <iframe> (which I assume needs to load completely before the rest of my web page is loaded), and thus adds a big amount of extra load time.
I tried moving the <script> tags to the bottom of the page, right before </body>, but the badges render just below the footer instead of where they need to be.
How can I force these two external javascript files to load last, but still render where they need to?

You could create a div ["divA"] where you want your Digg/Reddit iframes to go [So this is basically just a placeholder]. When the page is done loading, append a "script" element to head so the Digg/Reddit scripts can load. When they're done loading, you can move them from body to divA.
document.body.removeChild(iframe);
document.body.getElementById("divA").appendChild(iframe);

Where you render the script tags shouldn't necessarily imply where the UI those scripts generate appears-- that it does seems a goofy or questionably designed. Do the scripts have known functions in them that let you hand them a container div or something in which to render their UI?
You're correct, of course, in loading them last, before </body>. That's the right strategy.

The quick answer is - no simple way. If you user defer="true" on the script tags, and they use document.write, it will still write out the content where it was when it loaded and not where the script tag was inserted.
Some of the answers in this question might help you: How can I stop an IFrame reloading when I change it's position in the DOM?
Some of the other answers in this thread suggest removing the iframe and then reinserting it. However, that will lead you straight to the problem in the above-linked question -- it will cause the content of the iframe to load twice.
The general approach will be to put a placeholder where you want them and then move them into that placeholder when they are ready.

Optimal location for javascript includes

I've read that it is better to place your <script> tags at the end of the document. The argument for doing this appears to be that the browser will stall rendering the page below a script tag until it has loaded and and executed the script. If your script tag is at the top of the page, rendering is stalled for a while, which is bad.
However, I am not sure if this is really true any more.
Looking around, I normally see the following locations...
In the <head> of the page or Just inside the <body> tag
Stackoverflow is an example of a site that puts the script tags in the head, and since they are normally rather obsessed with performance, I am starting to wonder if position in the page is important at all.
Last thing in the body element
The other common place to put javascript appears to be right at the very end of the <body> element. I am assuming this means that the page can render while the javascript downloads and gets on with doing its thing.
But which is better?
Does anyone have any thoughts or advice on this? I am looking to try and get our pages to perform and appear to the user as quickly as possible.
Does it matter? What are the advantages of being at the top of the page? Bottom of the page?

It really depends.
There is no catch all answer for this because it depends on what your javascripts are acting on.
Putting scripts at the end of the page is sometimes needed if your acting on a DOM element that needs to be loaded for the script to run. Say you want to focus on a control and your script is:
var mytext = document.getElementById("mytext2");
mytext.focus();
Well in this case you would want it to execute at the end of the page, after mytext2 control has already been loaded by the browser. This is less important for script blocks that only contain functions that are called by events.
If you have a big .js file that contains libraries of functions you may also want to put that at the end of the page so the browser will load the page faster before loading the large .js file.
Google analytics suggests putting their tracker at the end, to make sure the page has been delivered before you count the hits, but in some cases it suggests putting the script into the header too, it works both ways.
So, rule of thumb for me is, HEAD scripts for everything except things that execute in-line and act on DOM objects, or large scripts that you want to load after the page.
Rick Strahl just wrote a great blog on placement of Javascript in .net too:

The only validating way is to include it on the top (in the <head> section), but in the bottom will be faster to load - the rest of the page will load faster if you have script near the bottom, giving the user better response and making the experience better.
The problem is that most web browser stop rendering the HTML of the page until they've fetched and parsed all JavaScript code so far. So if you have a slow-loaded .js file included in the <head>, no HTML will be rendered and images will not even start to download before the .js have been downloaded and parsed, therefore frontend engineers propagate for putting the scripts as far down in the code as possible.
I usually just set a far-future Expires header for my .js files so they are cached in the browser for a long time and then include them in the <head> section. This gives good performance and doesn't look ugly :-)
But if you are serving external .js libraries (that are on other servers than your own), you will probably want them in the bottom because you can't change the Expires-header for other servers and you canät know that the other server always will be responsive.

yeah. Put Scripts at the Bottom
I think the size of the js file is much more important than the location of javascript. I always set highter number of the con-current connection to make sure they download in parallel.

I believe it's better to place script tags just before the closing body tag. Because:
Elements are blocked from rendering if they are below the script.
In IE6, IE7 resources in the page are blocked from downloading if they are below the script.
From this article. Also Yahoo's performance rule 6 is Move Scripts to the Bottom

Google Analytics always used to say to put the script tag at the bottom of the page. I believe the rationale was that if the Google servers ever went down, the page would fail to load if it were in the head (only for IE probably).

JavaScript at bottom/top of web page?

I was just using the plugin "Yslow" for Mozilla Firefox, and it told me that I should put JavaScript at the bottom. I have heard this before but haven't really thought about it too much. Is there really an advantage in putting JavaScript at the bottom of a web page compared to the top?

It'll allow the web page to load visibly before executing JavaScript, which makes sense for things like Google Analytics, which don't need to happen before the page loads.
You may also want to look into things like jQuery, prototype, etc and attach to the "ready" handler, which executes JavaScript code after the DOM has been fully loaded, which is an appropriate place for much JavaScript code.

Assuming you aren't running on a CDN or aren't serving your JS from a separate sub-domain or server, it will load synchronously and force your HTML content to wait until it has downloaded the files. By placing the JS at the bottom of your page before the closing </body> tag, you are allowing the HTML to be parsed prior to loading the javascript. This gives the effect of faster page load times.

If you have static html content and a lot of javascript, it can make a difference in perceived page load time since the html will load first giving the user something to look at. If you don't have much javascript, or the existing page content relies on the javascript to be useful, then this is not as useful practically-speaking.

I want to bring update to this topic, google has recently introduced async snipped http://support.google.com/analytics/bin/answer.py?hl=en&answer=1008080&rd=1 which can be added for your site to bring e.g. google statistics support. It should be placed bottom of the <head> section for best performance. The point is that this increases likely hood of tracking beacon to be sent before user leaves the page.
Also it should be located there if you want to verify your site in google webmaster tools using your google analytics.
Other than that, same rules still applies basically - javascript at bottom for "fast" loading of the page. I used quotes because I dont count page fully loaded until javascript finishes ;-)

Yes, the page will load the content and render it before loading and executing javascript, and the page will, as a result, load faster.

TOP
When you put your JavaScript at the top of the page, the browser will start loading your JS files before the markup, images and text. And since browsers load JavaScript synchronously, nothing else will load while the JavaScript is loading. So there will be a timeframe of a few seconds where the user will see a blank page, while the JavaScript is loading.
BOTTOM
On the other hand, if you place your JavaScript at the bottom of the page, the user will see the page loading first, and after that the JavaScript will load in the background. So if, for example, your CSS & HTML takes 5 seconds to load, and your JavaScript takes another 5 seconds, putting our JavaScript on the top of the page will give the user a “perceived” loading time of 10 seconds, and putting it on the bottom will give a “perceived” loading time of 5 seconds.
Taken from Demian Labs.

It allows all the DOM elements to fully load before loading the Javascript which addresses them. This standard is also part of Visual Studio.

Placing scripts at the bottom of the element improves the display speed, because script compilation slows down the display.

Yes including the javascript at the bottom of the page really quickens the loading of the page. Since browser executes things synchronously it impacts the page loading if it is placed at the top of the page. If it is placed at the bottom of the page, the page would have loaded the entire markup by then when the browser starts loading the javascript giving a better experience to the user.

It's advisable to put all inline scripts at the end to improve performance, you don't want your users to be staring at a blank white screen while the script renders. You can use defer attribute eg. to prevent link scripts from delaying your html rendering.