すべてのテクノロジーと同様に、その長所と短所があります。 iframeを使用して適切に開発されたサイトを回避している場合、もちろんそれは悪い習慣です。ただし、iframeが許容される場合もあります。
Iframeの主な問題の1つは、ブックマークとナビゲーションに関係しています。コンテンツ内に単にページを埋め込むためにそれを使用している場合、私はそれでいいと思います。それがiframeの目的です。
ただし、iframeが悪用されていることも確認しています。サイトの不可欠な部分としてではなく、サイト内のコンテンツの一部として使用する必要があります。
通常、iframeを使用せずにそれを行うことができる場合は、より良いオプションです。ここにいる他の人たちは、より多くの情報やより具体的な例を持っていると思いますが、それはすべてあなたが解決しようとしている問題に帰着します。
とはいえ、HTMLに限定されており、PHPやASP.NETなどのバックエンドにアクセスできない場合は、iframeが唯一のオプションである場合があります。
それらは悪い習慣ではなく、単なる別のツールであり、柔軟性を追加します。
標準のページ要素として使用する場合は、コンテンツを複数のページに分離するシンプルで信頼性の高い方法であるため、優れています。特にユーザー生成コンテンツの場合、内部ページを「サンドボックス化」してiframeにすると、不適切なマークアップがメインページに影響を与えないので便利です。欠点は、スクロールの複数のレイヤー（ブラウザー用、iframe用）を導入すると、ユーザーがイライラすることです。 adzmが言ったように、プライマリナビゲーションにiframeを使用したくありませんが、ビデオや別のメディアファイルを埋め込む方法と同等のテキスト/マークアップと考えてください。
バックグラウンドイベントのスクリプティングでは、一般的に、現在のページのコンテンツをロードするために、iframeとXmlHttpRequestのどちらかを選択します。違いは、iframeがページのロードを生成するため、ほとんどのブラウザーでブラウザーキャッシュを前後に移動できることです。あらゆる場所でXmlHttpRequestを使用するGoogleは、特定の場合にiframesを使用して、ユーザーがブラウザーの履歴を前後に移動できるようにしていることに注意してください。
欠点を理解せずに使用するのは「悪い習慣」です。 Adzmの投稿はそれらを非常にうまくまとめています。
反対に、GmailはバックグラウンドでiFrameを多用し、一部の優れた機能（自動ファイルアップロードなど）を実現します。 iFrameの制限を知っているなら、iFrameを使用することについての自覚を感じるべきではないと思います。
多くの状況で彼らと協力してきたので、iframeはgotoステートメントに相当するWebプログラミングであると本当に思うようになりました。つまり、一般的に避けるべきものです。サイト内では、それらは多少役立つ場合があります。ただし、クロスサイトは、ほとんどの場合、最も単純なコンテンツ以外の場合、悪い考えです。
可能性を考慮してください...パラメータ化されたコンテンツに使用される場合、それらはインターフェースを作成しました。そして、プロフェッショナルなサイトでは、そのインターフェースにはSLAとバージョン管理が必要です-Rushではオンラインにするためにほとんど常に無視されます。
スクリプトをホストするフレームであるアクティブコンテンツに使用する場合、（異なる）クロスドメインスクリプトの制限があります。一部はハッキングされる可能性がありますが、一貫してハッキングされることはほとんどありません。また、フレーム化されたコンテンツがインタラクティブである必要がある場合、フレームを超えてそれを行うのに苦労します。
ライセンス付きコンテンツで使用する場合、参加サイトは、ホスト間で権利情報を帯域外に移動する必要があるため、負担になります。
そのため、サイト内で場合によっては便利ですが、マッシュアップにはあまり適していません。実際のポータルとポートレットを見る方がはるかに優れています。さらに悪いことに、彼らはすべてのウェブアマチュアの最愛の人です-多くの技術マネージャーが多くの問題の解決策として彼らを圧迫しています。実際、彼らはより多くを生み出します。
私の経験に基づいて、iframeのプラス側は、サードパーティコードを呼び出すときです。これには、Document.write();コマンド。ご存知かもしれませんが、これらのコマンドは解析方法（DOMパーサーなど）により非同期で呼び出すことはできません。この例は http://sourceforge.net/projects/phpadsnew/ phpadsnewsへの呼び出しが複数あり、サイトが待機していたため、iframeを使用してサイトのスピードアップを支援しました。ページのさまざまな部分のレンダリングに進む前の応答。 iframeを使用すると、サイトがページの他の部分をレンダリングできるようにし、phpadsのDocument.write()コマンドを非同期に呼び出すことができました。防止とjsロック。
Iframeのユーザーには間違いなく用途があります。天気ネットワークウィジェットをページに他にどのように配置しますか？他の唯一の方法は、XMLを取得して解析することですが、当然のことながら、恒久的な天気グラフィックを表示するための条件が必要です。
メインページがHTTPプロトコルで読み込まれ、ページの一部がHTTPSプロトコルで動作する必要がある場合、iFrameはjsonpに勝ちます。
特に、dataTypeがネイティブにjsonではなく、サーバー上でjsonに変換し、クライアント上で例えば複雑なhtml。
だからない-iFrameは悪ではありません。
元のフレームセットモデル（FramesetおよびFrame-elements）は、使いやすさの観点から非常に悪かった。 IFrameは、元のフレームセットモデルほど多くの問題はなかった後の発明ですが、欠点もあります。
ユーザーがIFrame内をナビゲートできるようにすると、リンクとブックマークは期待どおりに機能しません（iframeのURLではなく、外部ページのURLをブックマークするため）。
ダイナミックコンテキストメニューを作成する簡単な方法として、IFRAMEが非常にうまく適用されているのを見てきましたが、そのWebアプリの対象読者はInternet Explorerユーザーのみでした。
私はそれがすべてあなたの要件に依存すると言うでしょう。ページがすべてのブラウザーで等しく機能することを確認する場合は、IFRAMEを避けてください。狭くて有名なオーディエンス（例：ローカルイントラネット）をターゲットにしていて、IFRAMEを使用する利点がある場合は、そうすることは問題ないと思います。
悪くはありませんが、実際に役立ちます。 Twitterフィードを埋め込む必要があり、同じページでmdに実行させないという大きな問題があったので、別のページに設定して、iframeとして配置しました。
また、すべてのブラウザー（および電話ブラウザー）がそれらをサポートしているため、優れています。それらを正しく使用する限り、それらは悪い習慣とみなすことはできません。
Iframeは、ユーザーのインターネット接続の速度やiframeのコンテンツに関係なく、ページのダウンロード速度のわずかな（0.3秒程度）顕著な低下を引き起こすことに注意してください。これは、ローカルでテストするときに表示されるものではありません。実際、これはページに追加されたすべての要素に当てはまりますが、iframeの方が悪いようです。