Сравнение скорости - абсолютные и относительные пути


8

Допустим, я хочу сделать ссылку на родительский каталог ( http://example.com/library/) из подкаталога ( http://example.com/library/html/basics/).

Ссылка на родительский каталог может быть:

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

Есть ли разница в скорости в зависимости от того, как я пишу ссылку? Я не спрашиваю о скорости загрузки сайта, но есть ли заметная разница при переходе в каталог.


4
Почему вы думаете, что будет разница при обходе каталогов? Что касается сервера, то это всего лишь удар, пользователь фактически не будет «перемещаться» из одного каталога в другой - он просто запрашивает другой ресурс. Идет ли кто-то example.comсначала, а затем example.com/library/books/fiction/1984.htmlс «обходом» или без него, весь путь не имеет значения. И помните, что у вас будет несколько пользователей - один может запросить базовый каталог, а другой - глубоко вложенный, и сервер просто сделает ту же работу.
ВЛАЗ

1
Все 3 из этих URL-адресов идентичны, когда речь идет о HTTP-запросе, поэтому в том, что касается сервера, нет никакой разницы - браузер должен разрешить запрос http://example.com/library/во всех 3 случаях, иначе он просто недействителен.
MrWhite

Пока что упускается одна вещь - это влияние на содержание сайта. Использование /library/имеет следующие преимущества по сравнению с другими вариантами: вам не нужно обновлять все ссылки, если вы меняете свое доменное имя или переходите на SSL везде; если вы измените имя папки или переместите дочернюю папку, вы можете легко найти и заменить путь,
решая

Ответы:


9

Эффект для браузера:

Хотя это выглядит как небольшая работа для веб-браузера, но технически это не имеет большого значения. Браузеры слишком быстры, чтобы обрабатывать эти относительные структуры URL и выполнять вызовы к серверу приложений.

Эффект для Сервера приложений:

Нет, так как необходимо вернуть запрошенный файл (относительная / абсолютная ссылка в конечном итоге отображается на веб-путь)

Влияние на размер страницы:

Да, было бы некоторое уменьшение в размере (опять же, не то, что могло бы иметь огромное значение для производительности вашей страницы, что могло бы быть достигнуто с помощью чего-то вроде кодировки контента gzip или минимизации ресурса)

Поэтому я думаю, что технически абсолютные / относительные URL не имеют большого значения для скорости страницы / любой взвешиваемой матрицы .

Да, это имеет огромное значение в управлении несколькими средами, такими как dev, pp, prodpp и т. Д.

Пример: в вашей локальной разработке у вас может быть dev.example.com, а у вас может быть preproduction: pp.example.com. ,

Таким образом, в этих сценариях было бы относительно легко управлять кодом с относительными URL-адресами (хотя также можно управлять настройками среды)


2

Относительные пути на основе HTML / CSS всегда будут быстрее для скорости сервера, потому что на сервере меньше кода для отправки. Относительные пути в форме HTML или CSS переводятся браузером конечного пользователя, а не сервером.

Технически, это быстрее для сервера и медленнее для конечного пользователя, но конечный пользователь никогда не заметит разницы, поскольку требуемая обработка составляет менее наносекунд, поэтому конечные пользователи с большей вероятностью увидят разницу от относительный, потому что сервер сможет обслуживать их лучше.


«Относительные пути HTML / CSS всегда будут быстрее для скорости сервера, потому что у сервера меньше кода для отправки». Я действительно не верю этому. Хотя http://example.com/category/cats.htmlэто дольше /category/cats.html, я не вижу, чтобы это оказало достаточно существенное влияние на производительность, чтобы это даже можно было рассмотреть. Захват отправленных данных, который занимает доли секунды, уже покрыл бы «неэффективность размера» и любой «штраф скорости», который он налагает.
ВЛАЗ

Я сказал технически быстрее ... а ты выбираешь струны. даже с использованием кэшированного сжатия с использованием gzip html-страница с абсолютным и относительным относительным будет немного больше (относительное gz против абсолютного gz), следовательно, технически ... конечный пользователь должен декомпилировать этот gzip и разрешить относительное, это медленнее для конечный пользователь ... но это настолько мало, что конечный пользователь не заметит, опять же, это факт. Даже при использовании серверных технологий, таких как GZIP, сжатый HTML-файл или CSS-файл, использующий относительные пути и абсолютные, относительные всегда будут меньше в сжатом файле, опять же, это факт, попробуйте.
Саймон Хейтер

Хотя разница может составлять всего несколько байтов или несколько килобайт на страницах большего размера, экономия для одного посетителя невелика, но для миллионов пользователей это становится более заметным ... а значит, технически быстрее. Теперь, если вы спросите, стоит ли использовать относительный или абсолютный показатель для среднего веб-сайта с несколькими сотнями посещений в день? ответ, вероятно, нет ... но это был не тот вопрос, который задают.
Саймон Хейтер

Хит производительности, в лучшем случае, будет незначительным. Это может быть совершенно не существует, а также. Серверы, как правило, хороши в одном. Это от их имени - подача контента. Я не думаю, что несколько байтов или КБ будут проблемой. Это просто содержание, в конце. Если бы размер был проблемой, HTML-код, который мы пишем, выглядел бы совсем иначе. Это не тот случай. Минимизация контента предназначена исключительно для удобства пользователей, если их пропускная способность мала. Я уверен, что обработка запроса и ответа - это то, где производительность, а не фактический процесс отправки данных.
ВЛАЗ

1
«Относительные основанные пути всегда будут быстрее для скорости сервера», но ОП заявляет: «Я не спрашиваю о скорости загрузки сайта» - это единственное место, где сайт может быть быстрее. (Если честно, я не совсем уверен, о какой «скорости» говорит ОП?)
MrWhite,
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.