Comparação de velocidade - links de caminho absoluto vs relativo

Digamos que eu queira vincular a um diretório pai ( http://example.com/library/) a partir de um subdiretório ( http://example.com/library/html/basics/).

O link para o diretório pai pode ser:

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

Existe uma diferença de velocidade com base na maneira como escrevo o link? Não estou perguntando sobre a velocidade de carregamento do site, mas se há uma diferença notável ao percorrer o diretório.

— Jakub Kliský
fonte

Por que você acha que haveria uma diferença ao percorrer os diretórios? Na medida em que o servidor está em causa, é apenas um hit, o usuário não iria realmente ser "movendo-se" de um diretório para outro - eles estão apenas solicitar outro recurso. Se alguém vai example.comprimeiro e depois example.com/library/books/fiction/1984.htmlcom ou sem "atravessar" todo o caminho deve ser irrelevante. E lembre-se de que você terá vários usuários - um pode estar solicitando o diretório base, enquanto outro está profundamente aninhado e o servidor apenas está fazendo o mesmo trabalho.

— VLAZ 30/07

Todos os três URLs são idênticos quando se trata da solicitação HTTP; portanto, no que diz respeito ao servidor, não há diferença - o navegador deve resolver a solicitação http://example.com/library/nos três casos, caso contrário, simplesmente não é válido.

— MrWhite

Uma coisa perdida até agora é o efeito na manutenção do site. O uso /library/tem as seguintes vantagens sobre as outras opções: você não precisa atualizar todos os seus links se alterar seu nome de domínio ou mudar para SSL em qualquer lugar; se você alterar o nome da pasta ou mover a criança pasta pode encontrar & substituir o caminho facilmente, trabalhando fora o que precisa mudar a partir de ../ .. etc.

— Zhaph - Ben Duguid

Respostas:

Efeito para o navegador:

Embora isso pareça um pouco de trabalho para o navegador da web, mas tecnicamente não faz muita diferença. Os navegadores são rápidos demais para lidar com essa estrutura de URL relativa e fazer uma chamada para o servidor de aplicativos

Efeito para o servidor de aplicativos:

Nenhum, pois ele precisa retornar o arquivo solicitado (o link relativo / absoluto é mapeado para um caminho da web)

Efeito no tamanho da página:

Sim, haveria alguma redução no tamanho (novamente, algo que não faria muita diferença no desempenho da sua página, que poderia ser alcançado por algo como o codificador de conteúdo gzip ou o recurso de redução)

Então, eu acho que tecnicamente os URLs absolutos / relativos não fazem muita diferença na velocidade da página / em qualquer matriz ponderada .

Sim, faz uma enorme diferença no gerenciamento de vários ambientes, como dev, pp, prodpp etc.

Exemplo: no desenvolvimento local, você pode ter dev.example.com na pré-produção, pode ter: pp.example.com. .

Portanto, nesses cenários, seria relativamente fácil gerenciar código com URLs relativos (embora também possa ser gerenciado pelas configurações do ambiente)

— abhinsit
fonte

Os caminhos baseados em HTML / CSS sempre serão mais rápidos para a velocidade do servidor, porque o servidor tem menos código para enviar. Os caminhos relativos no formato HTML ou CSS são traduzidos pelo navegador do usuário final e não pelo servidor.

Portanto, tecnicamente, é mais rápido para o servidor e mais lento para o usuário final, mas o usuário final nunca notaria a diferença, já que o processamento necessário é menor que nano segundos, portanto, é mais provável que os usuários finais vejam a diferença entre relativo porque o servidor poderá atendê-los melhor.

— Simon Hayter
fonte

"Os caminhos baseados em HTML / CSS sempre serão mais rápidos para a velocidade do servidor, porque o servidor tem menos código para enviar." Eu realmente não acredito nisso. Embora http://example.com/category/cats.htmlseja mais longo que isso /category/cats.html, não vejo como isso tenha um impacto significativo no desempenho para ser considerado. Gzipar os dados enviados, que leva frações de segundo, já cobriria a "ineficiência de tamanho" e qualquer "penalidade de velocidade" que impor.

— VLAZ 30/07

Eu disse tecnicamente mais rápido ... e você está escolhendo cordas. mesmo com a compactação em cache usando gzip, uma página html com absoluto x relativo será um pouco maior (gz relativo x gz absoluto), portanto tecnicamente ... o usuário final precisa descompilar esse gzip e resolver o relativo, isso é mais lento para o usuário final ... mas isso é tão mínimo que o usuário final não notará, novamente isso é fato. Mesmo com tecnologias do lado do servidor, como GZIP, um arquivo HTML compactado ou CSS usando caminhos relativos versus absolutos, o relativo será sempre menor em um arquivo compactado; novamente, isso é fato, tente.

— Simon Hayter

Embora a diferença possa ser apenas alguns bytes ou alguns kb em páginas maiores, a economia para um visitante não é grande, mas nos milhões de usuários que se tornam mais visíveis ... portanto, tecnicamente mais rápido. Agora, se você está perguntando se vale a pena usar relativo x absoluto para o site médio, com apenas algumas centenas de visitas por dia? a resposta é provavelmente não ... mas essa não foi a pergunta que está sendo feita.

— Simon Hayter

O desempenho atingido, na melhor das hipóteses, será insignificante. Também poderia ser totalmente inexistente. Servidores geralmente são bons em uma coisa. Está no nome deles - veiculando conteúdo. Eu não acho que alguns bytes ou um KB seria um problema. É apenas conteúdo, no final. Se o tamanho fosse um problema, o HTML que escrevemos ficaria muito diferente. Esse não é o caso. A minificação do conteúdo é puramente para conveniência do usuário, caso a largura de banda seja pequena. Estou confiante de que o processamento da solicitação e a resposta é onde está o desempenho, não no ato real de enviar os dados.

— VLAZ 31/07

"os caminhos com base relativa sempre serão mais rápidos para a velocidade do servidor" - mas o OP afirma "Não estou perguntando sobre a velocidade de carregamento do site" - que é o único local em que o site pode ser mais rápido. (Para ser honesto, eu não sou realmente certo o que "velocidade" do OP está falando?)

— MrWhite