Perbandingan kecepatan - tautan jalur absolut dan relatif

Katakanlah saya ingin menautkan ke direktori induk ( http://example.com/library/) dari subdirektori ( http://example.com/library/html/basics/).

Tautan ke direktori induk dapat:

href="../../"
href="https://webmasters.stackexchange.com/library/"
href="http://example.com/library/"

Apakah ada perbedaan kecepatan berdasarkan cara saya menulis tautan? Saya tidak bertanya tentang kecepatan memuat situs web, tetapi apakah ada perbedaan yang nyata saat melintasi direktori.

— Jakub Kliský
sumber

Mengapa Anda berpikir akan ada perbedaan dalam melintasi direktori? Sejauh menyangkut server, itu hanya hit, pengguna tidak akan benar - benar "bergerak" dari satu direktori ke yang lain - mereka hanya meminta sumber daya lain. Apakah seseorang pergi example.compertama dan kemudian example.com/library/books/fiction/1984.htmldengan atau tanpa "melintasi" semua jalan seharusnya tidak relevan. Dan ingat bahwa Anda akan memiliki banyak pengguna - satu dapat meminta direktori basis, sementara yang lain bersarang mendalam dan server hanya akan melakukan pekerjaan yang sama.

— VLAZ

Ketiga URL tersebut identik ketika menyangkut permintaan HTTP, jadi sejauh menyangkut server, tidak ada perbedaan - browser harus menyelesaikan permintaan http://example.com/library/dalam ketiga kasus, jika tidak maka tidak valid.

— MrWhite

Satu hal yang terlewatkan sejauh ini adalah pengaruhnya terhadap pemeliharaan situs. Menggunakan /library/memiliki keunggulan berikut daripada opsi lain: Anda tidak perlu memperbarui semua tautan Anda jika Anda mengubah nama domain Anda atau pindah ke SSL di mana-mana; jika Anda mengubah nama folder, atau memindahkan folder anak Anda dapat menemukan & mengganti jalur dengan mudah, mencari tahu apa yang perlu diubah dari ../ .. dll.

— Zhaph - Ben Duguid

Jawaban:

Efek untuk browser:

Meskipun ini sepertinya sedikit bekerja untuk browser web, tetapi secara teknis itu tidak membuat banyak perbedaan. Browser terlalu cepat untuk menangani struktur url relatif ini dan melakukan panggilan ke server aplikasi

Efek untuk Server aplikasi:

Tidak ada, karena perlu mengembalikan file yang diminta (tautan relatif / absolut akhirnya memetakan ke jalur web)

Efek pada ukuran halaman:

Ya akan ada beberapa pengurangan ukuran (sekali lagi bukan sesuatu yang akan membuat perbedaan besar pada kinerja halaman Anda yang dapat dicapai dengan sesuatu seperti pengkodean konten gzip atau sumber daya minifying)

Jadi saya pikir secara teknis url absolut / relatif tidak membuat banyak perbedaan pada kecepatan halaman / matriks bobot .

Ya itu membuat perbedaan besar dalam mengelola beberapa lingkungan seperti dev, pp, prodpp dll

Contoh: pada pengembangan lokal Anda, Anda mungkin memiliki dev.example.com pada pra produksi, Anda mungkin memiliki: pp.example.com. .

Jadi dalam skenario itu akan relatif mudah untuk mengelola kode dengan url relatif (meskipun dapat dikelola oleh pengaturan lingkungan juga)

— abhinsit
sumber

Jalur relatif berbasis HTML / CSS akan selalu lebih cepat untuk kecepatan server, ini karena server memiliki lebih sedikit kode untuk dikirim. Jalur relatif dalam bentuk HTML atau CSS diterjemahkan oleh browser pengguna akhir dan bukan server.

Jadi secara teknis, ini lebih cepat untuk server dan lebih lambat untuk pengguna akhir, tetapi pengguna akhir tidak akan pernah melihat perbedaannya, karena pemrosesan yang diperlukan kurang dari nano-detik, oleh karena itu pengguna akhir jauh lebih mungkin untuk melihat perbedaan dari relatif karena server akan dapat melayani mereka dengan lebih baik.

— Simon Hayter
sumber

"Jalur berbasis HTML / CSS relatif akan selalu lebih cepat untuk kecepatan server, ini karena server memiliki lebih sedikit kode untuk dikirim." Saya benar-benar tidak percaya itu. Meskipun http://example.com/category/cats.htmllebih lama dari itu /category/cats.html, saya tidak dapat melihat ini memiliki dampak yang cukup signifikan pada kinerja untuk dipertimbangkan. Gzipping data yang dikirim, yang membutuhkan sepersekian detik, akan sudah mencakup "inefisiensi ukuran" dan apa pun "penalti kecepatan" yang diterapkannya.

— VLAZ

Saya memang mengatakan secara teknis lebih cepat ... dan Anda memilih string. bahkan dengan kompresi cache menggunakan gzip, halaman html dengan absolut vs relatif akan sedikit lebih besar (relatif relatif vs gz absolut), maka secara teknis ... pengguna akhir harus mendekompilasi gzip itu, dan menyelesaikan relatif, ini lebih lambat untuk pengguna akhir ... tetapi ini sangat minim sehingga pengguna akhir tidak akan memperhatikan, sekali lagi ini adalah fakta. Bahkan dengan teknologi sisi server seperti GZIP file HTML terkompresi, atau file CSS menggunakan jalur relatif vs absolut, relatif akan selalu lebih kecil dalam file terkompresi, sekali lagi ini adalah fakta, cobalah.

— Simon Hayter

Walaupun perbedaannya mungkin hanya beberapa byte, atau beberapa kb pada halaman yang lebih besar, penghematan untuk satu pengunjung bukanlah utama, tetapi dalam jutaan pengguna yang menjadi lebih terlihat ... karenanya, secara teknis lebih cepat. Sekarang, apakah Anda bertanya apakah layak menggunakan relatif vs absolut untuk situs web rata-rata dengan hanya beberapa ratus kunjungan sehari? jawabannya mungkin tidak ... tapi itu bukan pertanyaan yang ditanyakan.

— Simon Hayter

Pencapaian kinerja, paling-paling, akan diabaikan. Itu bisa sepenuhnya tidak ada, juga. Server umumnya bagus dalam satu hal. Ada dalam nama mereka - melayani konten. Saya tidak berpikir beberapa byte atau KB akan menjadi masalah. Itu hanya konten, pada akhirnya. Jika ukuran adalah masalah, HTML yang kita tulis akan terlihat sangat berbeda. Bukan itu masalahnya. Pengurangan konten murni untuk kenyamanan pengguna jika bandwidth mereka kecil. Saya yakin bahwa memproses permintaan dan merespons adalah di mana kinerjanya berada, bukan dalam tindakan aktual mengirimkan data.

— VLAZ

"jalur berbasis relatif akan selalu lebih cepat untuk kecepatan server" - tetapi OP menyatakan, "Saya tidak bertanya tentang kecepatan pemuatan situs web" - yang merupakan satu-satunya tempat di mana situs mungkin bisa lebih cepat. (Sejujurnya, saya tidak begitu yakin apa "kecepatan" yang dibicarakan OP?)

— MrWhite