一般に、相対的なURLを使用することがベストプラクティスと考えられているので、あなたのウェブサイトは現在展開されている場所のベースURLに束縛されないでしょう。たとえば、ローカルホストだけでなく、パブリックドメインでも変更なしに機能することができます。
絶対URLと相対URLのどちらを使用するべきですか？
絶対URLによってあなたが計画を含むURL（例えばhttp/https）とホスト名（例えばyourdomain.com）がそれをしないことを意味するなら（それは保守とデバッグがひどいでしょうから）（ローカルリソースのために）。
<img src="http://yourdomain.com/images/example.png">のように、コードの至る所で絶対URLを使用したとしましょう。今、あなたがしようとしているときに何が起こるでしょう：
- 別のスキームに切り替える（例：http - > https）
- ドメイン名を切り替える（test.yourdomain.com - > yourdomain.com）
最初の例では、安全でないコンテンツがページでリクエストされているという警告が表示されます。すべてのURLはhttp（：// yourdomain.com/images/example.png）を使用するようにハードコードされているためです。そして、httpであなたのページを走らせるとき、ブラウザは情報の漏洩を防ぐためにhttpsを通してロードされるべきすべてのリソースを期待します。
2番目の例では、サイトをテスト環境からライブにするときに、すべてのリソースがまだライブドメインではなくテストドメインを指していることを意味します。
絶対URLと相対URLのどちらを使用するかについての質問に答えるには、常に相対URLを使用します（ローカルリソース用）。
異なるURLの違いは何ですか？
最初に、使用できる違いのURLを見てみましょう。
http://yourdomain.com/images/example.png//yourdomain.com/images/example.png/images/example.pngimages/example.png
これらのURLはサーバー上でどのリソースにアクセスしようとしますか？
以下の例では、Webサイトはサーバー/var/www/mywebsite上の次の場所から実行されているとします。
http://yourdomain.com/images/example.png
上記の（絶対）URLは、リソース/var/www/website/images/example.pngにアクセスしようとします。このタイプのURLは、上記の理由から、自分のWebサイトからリソースを要求することを避けたい、alwaysのようなものです。しかしそれはその場所を持っていますか。たとえば、Webサイトhttp://yourdomain.comがあり、http経由で外部ドメインからリソースを要求したい場合は、これを使用する必要があります。例えば。 https://externalsite.com/path/to/image.png。
//yourdomain.com/images/example.png
このURLは現在使用されている方式に基づいており、外部リソース（画像、JavaScriptなど）を含める場合はほとんど常に使用する必要があります。
このタイプのURLがすることはそれがあるページの現在のスキームを使うことです。つまり、あなたはhttp://yourdomain.comページにいて、そのページには画像タグ<img src="//yourdomain.com/images/example.png">があり、その画像のURLはhttp://yourdomain.com/images/example.pngで解決されます。http**s**://yourdomain.comページにいて、そのページに画像タグ<img src="//yourdomain.com/images/example.png">がある場合、画像のURLはhttps://yourdomain.com/images/example.pngに解決されます。
これは、不要なときにhttpsを介してリソースをロードするのを防ぎ、isが必要なときにhttpsを介してリソースが要求されるように自動的にします。
上記のURLは、サーバー側では前のURLと同じ方法で解決されます。
上記の（絶対）URLは、リソース
/var/www/website/images/example.pngにアクセスしようとします。
/images/example.png
地域の資源については、これはそれらを参照するのに好ましい方法です。これはあなたのウェブサイトのドキュメントルート（/var/www/mywebsite）に基づいた相対URLです。これは<img src="/images/example.png">があるときはalways/var/www/mywebsite/images/example.pngに解決されることを意味します。
ある時点でドメインを切り替えることにした場合、それは相対的なものであるためまだ機能します。
images/example.png
これも相対URLですが、前のものとは少し異なります。このURLは現在のパスからの相対パスです。これが意味することはそれがあなたがサイトのどこにいるかに応じて異なるパスに解決されるということです。
例えば、あなたがhttp://yourdomain.comページにいて、<img src="images/example.png">を使うとき、それは予想通りに/var/www/mywebsite/images/example.pngに解決します、しかしあなたがあなたがhttp://yourdomain.com/some/pathページにいるとき、あなたはそれが突然/var/www/mywebsite/some/path/images/example.pngに解決するでしょう。
何を使うの？
外部リソースを要求するとき（あなたは別のスキームを強制したいのでなければ）スキームに相対的なURLを使いたいと思うでしょうそしてローカルリソースを扱うときあなたはドキュメントルートに基づいて相対的なURLを使いたいです。
サンプル文書
<!DOCTYPE html>
<html>
<head>
<title>Example</title>
<link href='//fonts.googleapis.com/css?family=Lato:300italic,700italic,300,700' rel='stylesheet' type='text/css'>
<link href="/style/style.css" rel="stylesheet" type="text/css" media="screen"></style>
</head>
<body>
<img src="/images/some/localimage.png" alt="">
<script src="//ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js" ></script>
</body>
</html>
いくつかの（ちょっと）重複
これを参照してください。 http://en.wikipedia.org/wiki/URI_scheme#Generic_syntax
foo://username:[email protected]:8042/over/there/index.dtb;type=animal?name=ferret#nose
\ / \________________/\_________/ \__/ \___/ \_/ \_________/ \_________/ \__/
| | | | | | | | |
| userinfo hostname port | | parameter query fragment
| \_______________________________/ \_____________|____|____________/
scheme | | | |
| authority |path|
| | |
| path interpretable as filename
| ___________|____________ |
/ \ / \ |
urn:example:animal:ferret:nose interpretable as extension
絶対URLには "path"部分の前の部分が含まれます。つまり、スキーム（http://foo/bar/bazのhttp）とホスト名（http://foo/bar/bazのfoo）（およびオプションでport、userinfo、およびport）が含まれます。
相対URLはパスで始まります。
絶対URLは、絶対、絶対URLです。リソースの場所は、URL自体を見るだけで解決できます。相対URLはある意味で不完全です。それを解決するには、スキームとホスト名が必要です。これらは通常、現在のコンテキストから取得されます。たとえば、次のWebページにあります。
http://myhost/mypath/myresource1.html
あなたはそのようにリンクを張ることができます
<a href="pages/page1">click me</a>
リンクのhref属性では、相対URLが使用され、クリックされた場合はそれをたどるために解決する必要があります。この場合、現在のコンテキストは
http://myhost/mypath/myresource1.html
そのため、これらのスキーマ、ホスト名、および先頭パスが取得され、pages/page1の前に追加されます。
http://myhost/mypath/pages/page1
リンクがあった場合：
<a href="/pages/page1">click me</a>
（/がURLの先頭に表示されていることに注意してください）それからそれは次のように解決されたでしょう
http://myhost/pages/page1
先頭の/はホストのルートを示すからです。
Webアプリケーションでは、私はあなたのアプリに属するすべてのリソースに相対URLを使用することをお勧めします。そうすれば、ページの場所を変更しても、すべてが機能し続けます。外部リソース（アプリケーションの完全に外部にあるページだけでなく、コンテンツ配信ネットワークを介して配信する静的コンテンツも含む）は常に絶対URLを使用して指す必要があります。別のサーバーに常駐する。
ファイルがフォルダー内にあるサブサイトを作成しているとします。 http://site.ru/shop 。
1.絶対URL
Link to home page
href="http://sites.ru/shop/"
Link to the product page
href="http://sites.ru/shop/t-shirts/t-shirt-life-is-good/"
2.相対URL
Link from home page to product page
href="t-shirts/t-shirt-life-is-good/"
Link from product page to home page
href="../../"
相対URLは絶対URLより短く表示されますが、リンクはサイトのどのページでも変更なしに使用できるため、絶対URLの方が適しています。
中間ケース
私たちは二つの極端なケースを考えました：「絶対的に」絶対的な、そして「絶対的に」相対的なURL。しかし、この世界ではすべてが相対的です。これはURLにも当てはまります。絶対URLについて言うたびに、常に相対URLを指定する必要があります。
3.プロトコル相対URL
Link to home page
href="//sites.ru/shop/"
Link to product page
href="//sites.ru/shop/t-shirts/t-shirt-life-is-good/"
GoogleはそのようなURLをお勧めします。しかし今では、一般的にhttp：//とhttps：//は別のサイトであると考えられています。
4.ルート相対URL
すなわちドメインのルートフォルダに対する相対パス。
Link to home page
href="/shop/"
Link to product page
href="/shop/t-shirts/t-shirt-life-is-good/"
すべてのページが同じドメイン内にある場合、それは良い選択です。サイトを別のドメインに移動したときに、URLのドメイン名をまとめて置き換える必要はありません。
5.ベース相対URL（ホームページ相対）
タグ<base>は、ベースURLを指定します。これは、すべての相対リンクとアンカーに自動的に追加されます。ベースタグは絶対リンクには影響しません。ベースURLとして、ホームページを指定します。<base href = "http://sites.ru/shop/">.
Link to home page
href=""
Link to product page
href="t-shirts/t-shirt-life-is-good/"
これで、サイトを任意のドメインだけでなく、任意のサブフォルダに移動できます。 URLは相対的なもののように見えますが、実際には絶対的なものです。特にアンカーに注意を払ってください。現在のページ内を移動するには、href = "＃comments"ではなく、href = "t-shirts/t-shirt-life-is-good /＃comments"と書く必要があります。後者はホームページを投げるでしょう。
結論
内部リンクにはベース相対URL（5）を使います。外部リンクやニュースレターには絶対URL（1）を使います。
明示的に論じるべき3つのタイプが本当にあります。実際には、URLはより低いレベルで処理されるように抽象化されていますが、開発者は1つのURLを手作業で書かなくても全生涯を通れると言えるでしょう。
絶対の
絶対URLはコードをプロトコルとドメインに結び付けます。これは動的URLで克服することができます。
<a href=“https://dev.example.com/a.html?q=”>https://dev.example.com/a.html?q=</a>
絶対的な長所：
制御 - サブドメインとプロトコルを制御できます。あいまいなサブドメインを通って入る人々は適切なサブドメインにまとめられます。必要に応じて、セキュアと非セキュアの間を行き来できます。
設定可能 - 開発者は物事が絶対であることが大好きです。絶対URLを使用する場合は、きちんとしたアルゴリズムを設計できます。 URLを構成可能にして、単一の構成ファイルを1回変更するだけでURLをサイト全体で更新できるようにすることができます。
Clairvoyance - あなたのサイトを削っている人を検索するか、あるいはいくつかの余分な外部リンクを拾うことができます。
ルート相対
ルート相対URLは、コードをベースURLに結び付けます。これは動的なURLや ベースタグ で解決できます。
<a href=“/index.php?q=”>.example.com/index.php?q=</a>
根本的な長所：
- 設定可能 - baseタグはあなたが選択した任意のルートに対して相対的なものにし、ドメインの切り替えやテンプレートの実装を容易にします。
相対的な
相対URLはコードをディレクトリ構造に結び付けます。これを克服する方法はありません。相対URLは、ファイルシステム内でディレクトリをトラバースする場合、または単純な作業のショートカットとしてのみ役立ちます。
<a href=“index.php?q=”>index.php?q=</a>
<link src=“../.././../css/default.css” />
相対的な短所：
紛らわしい - それは何ドットですか？それはいくつのフォルダですか？ファイルはどこにありますか？なぜうまくいかないのですか？
MAINTENANCE - ファイルが誤って移動されてリソースがロードを終了した場合、リンクが誤ったページにユーザーを送信し、フォームデータが誤ったページに送信されることがあります。 。ファイルを移動する必要がある場合は、ロードを中止する予定のすべてのリソースと、正しくない予定のすべてのリンクを更新する必要があります。
スケールしない - Webページがより複雑になり、ビューが複数のページにまたがって再利用され始めると、相対リンクはそれらが含まれていたファイルに対する相対リンクになります。すべてのページに表示されるHTMLのナビゲーションスニペットがある場合、相対はさまざまな場所を基準にしたものになります。テンプレートの作成を始めるときに最初に気付くのは、URLを管理する方法が必要だということです。
計算 - それらはあなたのブラウザで実装されています（うまくいけばRFCに従って）。 RFC3986 の第5章を参照してください。
おっと！ - エラーや入力ミスによって蜘蛛の罠が発生することがあります。
ルートの進化
ここで説明しているという意味で、開発者はURLの作成を中止しました。すべてのリクエストはウェブサイトのインデックスファイルに対するもので、クエリ文字列、別名ルートを含みます。このルートは、生成されるコンテンツをアプリケーションに通知するミニURLと考えることができます。
<a href="<?=Route::url('named_url', array('first' => 'my', 'last' => 'whacky'))?>">
http://dev.example.com/index.php/my:whacky:url
</a>
ルートプロ：
- 絶対URLのすべての利点.
- URLに任意の文字を使用する.
- もっとコントロールできます（SEOに向いています）。
- アルゴリズム的にURLを生成する機能これにより、URLを設定可能にすることができます。 URLを変更することは、1つのファイルに1つの変更を加えることです。
- 404が見つかりませんの必要はありません。代替ルートは、サイトマップまたはエラーページを表示することがあります。
- アプリケーションファイルへの間接アクセスの便利なセキュリティ。ガードステートメントは、誰もが適切な経路を介して到着していることを確認できます。
- MVCアプローチの実用性.
私のテイク
ほとんどの人は、何らかの形でプロジェクトで3つの形式すべてを利用します。重要なのは、それらを理解し、そのタスクに最も適したものを選択することです。
私はここで大多数に反対しなければならないでしょう。
特に、開発者が少ない（または自分だけの）プロジェクトが小さい場合は、相対URLスキームはすぐに使用できるようにしてすぐに使用できるようにしたいときには「素晴らしい」と思います。
ただし、ドメインとプロトコルを常に切り替える大規模で脂肪の多いシステムで作業を開始すると、より洗練された方法が適切であると考えられます。
絶対URLと相対URLを本質的に比較すると、Absoluteが優先されます。どうして？壊れないからです。今まで絶対URLは正確にそれが言うことです。あなたがあなたの絶対URLを維持しなければならないとき、キャッチはあります。
絶対URLリンクへの弱いアプローチは、実際にはURL全体をハードコーディングすることです。それは素晴らしい考えではありません、そしておそらく人々がそれらを維持するのが危険/悪/迷惑であるとみなす理由の原因です。もっと良い方法は、使いやすいURLジェネレータを自分で書くことです。これらは書きやすく、信じられないほど強力に強力に - 自動的にプロトコルを検出し、設定が簡単です（文字通りアプリ全体のURLを一度設定します）、など、あなた自身のドメインをすべて注入します。それについてのいいところ：あなたは相対URLを使ってコーディングを続け、そして実行時にアプリケーションはその場で完全な絶対名としてあなたのURLを挿入します。驚くばかり。
現代のすべてのサイトがある種の動的バックエンドを実際にどのように使用しているかを考えると、そのようにすることがそのサイトの最大の利益になります。絶対URLは、単に指し示す場所を特定するだけではなく、SEOのパフォーマンスも向上させることができます。
私は、絶対URLがどういうわけかページのロード時間を変更しようとしているという議論が神話であると付け加えるかもしれません。あなたのドメインが数バイト以上の重さがあり、あなたが1980年代にダイアルアップモデムを使っているなら、確かに。しかし、それはもはや当てはまりません。 https://stackoverflow.com/ は25バイトですが、サイトのナビゲーションエリアに使用する "topbar-Sprite.png"ファイルは9 + kbです。これは、追加のURLデータがSpriteファイルと比較してロードされたデータの0.2％であることを意味し、そのファイルは大きなパフォーマンスヒットとは見なされていません。
この大きくて最適化されていないフルページの背景画像は、読み込み時間を遅くする可能性がはるかに高いです。
相対URLを使用しない理由についての興味深い投稿は次のとおりです。 http://yoast.com/relative-urls-issues/
たとえば、親戚で発生する可能性のある問題は、サーバーのマッピング（大規模なプロジェクトでは気にする必要があります）がファイル名と一致しないことがあり、開発者は相対URLについて想定しないことがあります。本当です。私が今行っているプロジェクトでそのことを今日見たところ、ページ全体が下がってしまいました。
あるいは、開発者がポインタを切り替えるのを忘れて、突然グーグルがあなたのテスト環境全体を索引付けしたのかもしれません。コンテンツが重複しています（SEOには不適切です）。
Absolutesは危険なものになることがありますが、正しく使用された場合ビルドを中断できないように信頼されることが証明されています。上の記事を見てください。なぜWordpressのURLジェネレータがすごいのかという理由がたくさんあります。
:)
Webサイト内で使用する場合は、Webサイトを別のドメイン名に移動するかローカルでデバッグする必要がある場合は、このように相対URLを使用することをお勧めします。
Stackoverflowが何をしているのか見てみましょう（Firefoxではctrl + U）：
<a href="/users/recent/90691"> // Link to an internal element
場合によっては、それらは絶対URLを使用します。
<link rel="stylesheet" href="http://sstatic.net/so/all.css?v=5934">
...これは速度を向上させるためのベストプラクティスです。あなたの場合、あなたがそのようなことをしているようには見えないので、私はそれについて心配しないでしょう。
ほとんどの場合、相対URLを使用するのが本来の方法です。つまり、サイトを持ち上げて他の場所に即座に機能させたい場合は、デバッグ時間を短縮できます。
かなりまともなものがあります 絶対URLと相対URLの記事 、それをチェックしてください。
URLスキームおよびスキーム固有の部分（http://、https://、ftp://など）で始まるURLは絶対URLです。
他のURLは相対URLであり、相対URLが解決される（したがって依存する）ベースURLが必要です。つまり、他に宣言されていない場合、参照が使用されるリソースのURLです。
相対URLの解決例については、 RFC 2396 - 付録C をご覧ください。
サイトwww.yourserver.comがあるとしましょう。 Webドキュメントのルートディレクトリにはサブディレクトリの画像があり、その中にはmyimage.jpgがあります。
絶対URLは、ドキュメントの正確な場所を定義します。次に例を示します。
http://www.yourserver.com/images/myimage.jpg
相対URLは場所を定義します現在のディレクトリからの相対位置、例えば、あなたがあなたのイメージがあるルートウェブディレクトリにいるならば：
images/myimage.jpg
（そのルートディレクトリからの相対パス）
可能な場合は常に相対URLを使用してください。サイトをwww.anotherserver.comに移動した場合、www.yourserver.comを指しているすべての絶対URLを更新する必要がありますが、相対URLはそのまま機能し続けます。
相対URI解決をサポートするすべてのシステムで、相対URIと絶対URIの両方が同じ目的を果たします。それは参照です。そしてそれらは互換的に使用することができます。ですから、それぞれのの場合で違う方法で決めることができます。技術的には、同じの参照を提供します。
正確には、各相対URIにはすでに絶対URIがあります。そしてそれが相対URIが解決されるベースURIです。したがって、相対URIは実際には絶対URIの上にある機能です。
また、相対URIでは絶対URIだけでなくもっとできるようになるのもその理由です。絶対URIに比べて柔軟に維持できます。
相対URI解決のこれらの良い効果は、動的Webアプリケーション開発にも利用できます。絶対URIが導入する柔軟性の欠如は、動的環境で対処するのもより簡単です。そのため、URI解決とそれを正しく実装し管理する方法がわからない開発者にとっては、絶対URIの使用を選択することがよくあります。 Webサイトの動的な部分にあるURIは、他の動的な機能（URI接頭辞を含む設定変数など）を導入する可能性があるため、柔軟性がありません。
それでは、絶対URIを使用する利点は何ですか？技術的にはありませんが、相対URIは、いわゆる絶対ベースURIに対して解決する必要があるため、より複雑です。この解決方法は何年もの間厳密に定義されていますが、URI解決に誤りのあるクライアントを介して実行する可能性があります。絶対URIは解決を必要としないため、絶対URIを使用しても相対URI解決でクライアントの動作が誤ってしまう危険性はありません。それで、そのリスクは実際どのくらい高いのでしょうか。まあ、それは非常にまれです。相対的なURI解決に問題があるインターネットブラウザは1つだけです。そしてそれは一般的なことではなく、非常に（あいまいな）場合だけのことでした。
HTTPクライアント（ブラウザ）の隣には、ハイパーテキスト文書やコードの作成者にとってもおそらくもっと複雑です。ここで絶対URIを使用すると、ブラウザのアドレスバーにそのまま入力できるので、テストが簡単になります。ただし、1時間だけの仕事ではない場合は、絶対および相対URI処理を実際に理解し、相対リンクの利点を実際に活用できるようにすると、より多くの利点が得られます。