回答:
一般に、相対URLを使用することがベストプラクティスであると考えられているため、Webサイトは現在展開されている場所のベースURLにバインドされません。たとえば、変更を加えなくても、ローカルホストだけでなくパブリックドメインでも機能します。
絶対URLとは、スキーム（http / httpsなど）とホスト名（yourdomain.comなど）を含むURLを意味しません（ローカルリソースの場合）。これは、保守とデバッグが非常に困難になるためです。
たとえば、コード内のどこでも絶対URLを使用したとします<img src="http://yourdomain.com/images/example.png">。今、あなたがしようとしているときに何が起こるでしょう：
最初の例では、ページで要求されている安全でないコンテンツについて警告が表示されます。すべてのURLがhttp（：//yourdomain.com/images/example.png）を使用するようにハードコードされているためです。また、httpsを介してページを実行する場合、ブラウザはすべてのリソースがhttpsを介してロードされ、情報の漏洩を防ぐことを期待します。
2番目の例では、サイトをテスト環境からライブに移行する場合、すべてのリソースがまだライブドメインではなくテストドメインを指していることを意味します。
したがって、絶対URLを使用するか相対URLを使用するかについての質問に答えるには、常に（ローカルリソースの）相対URLを使用します。
まず、使用できるさまざまなタイプのURLを見てみましょう。
http://yourdomain.com/images/example.png//yourdomain.com/images/example.png/images/example.pngimages/example.png以下の例では、サーバー上の次の場所からWebサイトが実行されていると想定しています/var/www/mywebsite。
http://yourdomain.com/images/example.png
上記の（絶対）URLはリソースへのアクセスを試みます/var/www/website/images/example.png。このタイプのURLは、上で概説した理由により、自分のWebサイトからリソースを要求することを常に避けたいものです。ただし、その場所はあります。たとえば、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を介して読み込まれることがなくなり、リソースが必要なときにhttpsを介してリソースが自動的に要求されるようになります。
上記のURLは、前のURLと同じ方法でサーバー側で解決されます。
上記の（絶対）URLはリソースへのアクセスを試みます
/var/www/website/images/example.png。
/images/example.png
ローカルリソースの場合、これはリソースを参照するための好ましい方法です。これは、/var/www/mywebsiteWebサイトのドキュメントルート（）に基づく相対URLです。つまり、持っている<img src="/images/example.png">場合は常にに解決され/var/www/mywebsite/images/example.pngます。
ある時点でドメインを切り替えることにした場合、それは相対的であるため、ドメインは引き続き機能します。
images/example.png
以前のURLとは少し異なりますが、これも相対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:password@example.com: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には、「パス」部分の前の部分が含まれます。つまり、スキーム（httpin http://foo/bar/baz）とホスト名（fooin http://foo/bar/baz）（およびオプションでポート、ユーザー情報、ポート）が含まれます。
相対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を使用するように指示する必要があります。別のサーバーに常駐します。
//example.com/…、?foobarおよびこれ#foobarも相対URLであり、URLパスで始まっていません（まあ?foobar、空のパスで始まっていると言うことができるためです）。
//example.com/…タイプのURLは相対と呼ばれますか？それは私にとって新しいです。
ファイルがフォルダーhttp://site.ru/shopにあるサブサイトを作成するとします。
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/"
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の2つの極端なケースを検討しました。しかし、すべてはこの世界では相対的です。これはURLにも適用されます。絶対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：//は異なるサイトであると見なされています。
つまり、ドメインのルートフォルダを基準にしています。
Link to home page
href="/shop/"
Link to product page
href="/shop/t-shirts/t-shirt-life-is-good/"
すべてのページが同じドメイン内にある場合に適しています。サイトを別のドメインに移動する場合、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は相対的に見えますが、実際には絶対的なURLであることに注意してください。特にアンカーに注意してください。現在のページ内を移動するには、href = "＃comments"ではなくhref = "t-shirts / t-shirt-life-is-good /＃comments"と記述する必要があります。後者はホームページにスローされます。
内部リンクには、ベース相対URL（5）を使用します。外部リンクとニュースレターには絶対URLを使用します（1）。
明示的に説明する必要のあるタイプは本当に3つあります。実際には、URLはより低いレベルで処理されるように抽象化されていますが、開発者は単一のURLを手動で記述しなくても、自分の人生全体を通過できると言っていいでしょう。
絶対URLは、コードをプロトコルとドメインに結び付けます。これは動的URLで克服できます。
<a href=“https://dev.example.com/a.html?q=”>https://dev.example.com/a.html?q=</a>絶対的な長所：
制御 -サブドメインとプロトコルを制御できます。あいまいなサブドメインを通って入る人々は適切なサブドメインに集められます。必要に応じて、セキュアと非セキュアの間を行き来できます。
構成可能 -開発者は物事が絶対的なものであることを好みます。絶対URLを使用するときに、きちんとしたアルゴリズムを設計できます。URLを構成可能にして、1つの構成ファイルを1回変更するだけで、サイト全体でURLを更新できるようにすることができます。
Clairvoyance-あなたはあなたのサイトをかき集めている人々を検索するか、多分いくつかの追加の外部リンクを拾うことができます。
ルート相対URLは、コードをベースURLに結び付けます。これは、動的URLやベースタグ、あるいはその両方で解決できます。
<a href=“/index.php?q=”>.example.com/index.php?q=</a>ルート相対長所：
相対URLは、コードをディレクトリ構造に結び付けます。これを克服する方法はありません。相対URLは、ファイルシステムでディレクトリをトラバースする場合、または単純なタスクのショートカットとしてのみ役立ちます。
<a href=“index.php?q=”>index.php?q=</a>
<link src=“../.././../css/default.css” />相対的な短所：
混乱 -ドットはいくつですか？それはいくつのフォルダですか？ファイルはどこにありますか？なぜ機能しないのですか？
メンテナンス -ファイルが誤って移動された場合、リソースがロードを中止し、リンクがユーザーを間違ったページに送り、フォームデータが誤ったページに送られる可能性があります。ファイルを移動する必要がある場合は、ロードを中止するすべてのリソースと、正しくなくなるすべてのリンクを更新する必要があります。
スケールしない-Webページがより複雑になり、ビューが複数のページで再利用され始めると、相対リンクはそれらが含まれていたファイルに相対的になります。すべてのページに配置されるHTMLのナビゲーションスニペットがある場合、相対は多くの異なる場所に対して相対的になります。テンプレートの作成を開始するときに最初に気づくのは、URLを管理する方法が必要であることです。
COMPUTED-彼らはあなたのブラウザによって実装されています（うまくいけばRFCに従って）。RFC3986の第5章を参照してください。
おっとっと！-エラーまたはタイプミスは、スパイダートラップを引き起こす可能性があります。
ここで説明している意味で、開発者はURLの記述をやめました。すべてのリクエストはWebサイトのインデックスファイルに対するものであり、クエリ文字列、つまりルートが含まれています。ルートは、生成されるコンテンツをアプリケーションに通知するミニURLと考えることができます。
<a href="<?=Route::url('named_url', array('first' => 'my', 'last' => 'whacky'))?>">
http://dev.example.com/index.php/my:whacky:url
</a>ルートプロ：
ほとんどの人は、何らかの形でプロジェクトで3つすべてのフォームを使用します。重要なのは、それらを理解し、タスクに最適なものを選択することです。
Webサイト内で使用する場合は、相対URLを使用することをお勧めします。このように、Webサイトを別のドメイン名に移動するか、ローカルでデバッグする必要がある場合は、このようにすることができます。
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を本質的に比較すると、Absoluteが優先されます。どうして？壊れないから。ずっと。絶対URLは、まさにそのとおりです。問題は、絶対URLを維持する必要がある場合です。
絶対URLリンクへの弱いアプローチは、実際にはURL全体をハードコーディングすることです。素晴らしいアイデアではなく、おそらく人々がそれらを維持するのに危険/悪/迷惑であると見なす理由の犯人です。より良い方法は、自分で使いやすいURLジェネレータを作成することです。これらは簡単に記述でき、非常に強力です。プロトコルを自動的に検出したり、簡単に構成したり（文字どおりアプリ全体でURLを1回設定するなど）、ドメインを自動的に挿入したりできます。これの良い点は、相対URLを使用してコーディングを続け、実行時にアプリケーションが実行中に完全な絶対URLとしてURLを挿入することです。驚くばかり。
現代のすべてのサイトが何らかの動的なバックエンドをどのように使用しているかを考えると、そのようにすることは、そのサイトの最大の利益になります。絶対URLは、どこを指しているのかを確認するだけでなく、SEOのパフォーマンスを向上させることもできます。
絶対URLがどういうわけかページのロード時間を変更するという議論は神話であると付け加えるかもしれません。ドメインの重量が数バイトを超えていて、1980年代にダイヤルアップモデムを使用している場合は、間違いありません。しかし、それはもはやそうではありません。https://stackoverflow.com/は25バイトですが、サイトのナビゲーション領域に使用する「topbar-sprite.png」ファイルは9+ kbです。つまり、追加のURLデータは、スプライトファイルと比較してロードされたデータの.2％であり、そのファイルは大きなパフォーマンスヒットとは見なされていません。
大きくて最適化されていないフルページの背景画像は、読み込み時間を遅くする可能性がはるかに高くなります。
相対URLを使用してはならない理由についての興味深い投稿は、次のとおりです。http： //yoast.com/relative-urls-issues/
たとえば、親戚で発生する可能性のある問題は、サーバーマッピング（大規模でめちゃくちゃにされたプロジェクトでは注意が必要）がファイル名と一致せず、開発者がそうではない相対URLについて仮定する場合があることです本当。今日私が取り組んでいるプロジェクトでそれを見ただけで、ページ全体がダウンしました。
または、開発者がポインタを切り替えるのを忘れて、突然Googleがテスト環境全体にインデックスを付けた可能性があります。おっと-コンテンツが重複しています（SEOには不向きです！）。
絶対は危険な場合がありますが、適切に使用し、ビルドを壊さない方法で使用すると、信頼性が向上することが証明されています。上記の記事をご覧ください。WordpressのURLジェネレーターが非常に優れている理由がたくさんあります。
:)
/か、それともベースパスへのリンクに使用していますか？すなわち/products/wallets/thing.html、反対でthing.htmlはなくhttp://www.myshop.com/products/wallets/thing.html
echo Route::url('route_name')、サイトのURLを使用して絶対URLを作成し、HTTPS経由で作成するオプションを使用してルート情報を作成できます。
URLスキーム及びスキームの特定部分（で始まることURL http://、https://、ftp://、等）は絶対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は、現在のディレクトリからの相対位置を定義します。たとえば、画像が存在するルートWebディレクトリにいるとします。
images/myimage.jpg（そのルートディレクトリに対して）
可能な場合は常に相対URLを使用する必要があります。サイトをwww.anotherserver.comに移動する場合、www.yourserver.comを指しているすべての絶対URLを更新する必要があります。相対URLはそのまま動作し続けます。
相対URI解決をサポートするすべてのシステムで、相対URIと絶対URIの両方が同じ目的である参照を果たします。そして、それらは互換的に使用できます。したがって、それぞれ異なる方法で決定することができます。技術的には、それらは同じ参照を提供します。
正確には、各相対URIにはすでに絶対URIがあります。そして、それは相対URIが解決されるベースURIです。したがって、相対URIは実際には絶対URIに加えられた機能です。
相対URIを使用すると、絶対URIだけを使用した場合よりも多くのことができるのもこのためです。これは、絶対URIに比べて柔軟に維持できない静的Webサイトでは特に重要です。
相対URI解決のこれらのプラスの効果は、動的Webアプリケーション開発にも利用できます。絶対URIが導入する柔軟性の欠如は、動的環境で対処するのも簡単です。そのため、URI解決とそれを適切に実装および管理する方法（常に簡単ではない）がわからない一部の開発者は、しばしば絶対URIの使用を選択します。 Webサイトの動的な部分のURIは、他の動的な機能（URIプレフィックスを含む構成変数など）を導入して、柔軟性のない問題を回避できるためです。
では、絶対URIを使用する利点は何でしょうか。技術的にはそうではありませんが、私が言う1つは、相対URIは、いわゆる絶対ベースURIに対して解決する必要があるため、より複雑です。何年にもわたって解像度が厳密に定義されていても、URI解決に誤りのあるクライアントに出くわす可能性があります。絶対URIは解決を必要としないため、絶対URIを使用しても、相対URI解決でクライアントの動作に問題が発生するリスクはありません。では、実際にはそのリスクはどれほど高いのでしょうか。まあ、それは非常にまれです。相対URI解決に問題があった1つのインターネットブラウザーについてのみ知っています。そして、それは一般的ではなく、非常に（あいまいな）ケースでのみでした。
HTTPクライアント（ブラウザ）の隣では、ハイパーテキストドキュメントやコードの作成者にとっても、おそらくもっと複雑です。ここで、絶対URIには、ブラウザのアドレスバーにそのまま入力できるため、テストが簡単になるという利点があります。ただし、1時間の作業だけでなく、相対リンクの利点を実際に活用できるように、絶対および相対URI処理を実際に理解することは、多くの場合、より多くの利点があります。