Carregando o javascript principal em todas as páginas? Ou dividi-lo em páginas relevantes?


13

Eu tenho um 700kbarquivo JS descompactado que é carregado em todas as páginas. Antes eu tinha 12arquivos javascript em cada página, mas para reduzir as solicitações HTTP, eu as compactava 1 file.

Este arquivo é ~130kb gzippede é servido sobre gzip. No entanto, no computador local, ele ainda é descompactado e carregado em todas as páginas. Isso é um problema de desempenho?

Eu criei um perfil do javascript com o perfil do firebug, mas não vi nenhum problema. O problema / ilusão que estou enfrentando é que existem bibliotecas de jquery compactadas nesse arquivo que às vezes não são usadas na página atual.

Por exemplo, o jquery datatablesé compactado em 200kb e é carregado apenas em duas das páginas do meu site. Outra é jqplote essa é outra 200kb.

Agora tenho 400kbexcesso de código que não é executado nas 80%páginas.

Devo deixar tudo em um arquivo?

Devo remover as bibliotecas jquery e carregar apenas JS relevante na página atual?


Se você tem 700kb de código JS, realmente deve dividi-lo novamente e incluir apenas os scripts que realmente precisa. Além disso, usando jQuery ("... escreva menos, faça mais ...") parece um pouco grande demais ter um arquivo JS tão grande. O que diabos você está fazendo com tanta massa de JS?
Fee

@feeela dê uma olhada em jquery-ui, jquery.datatables. Só esses são 400kb juntos. Eu tenho outros plugins que eu também uso, como jquery.validate, jquery.uniform - esse material se soma. xD
Kyle

Nesse caso - como disse abaixo - você realmente deve dividir os scripts e coloque apenas o que é necessário ...
feeela

Respostas:


6

Você pode usar o requirejs para carregar dinamicamente as bibliotecas necessárias apenas nessas páginas. Depois, você só precisa carregar o requirejs (que é de cerca de 14k) em todas as páginas, economizando cerca de 385kb.

A integração também é muito fácil: basta "embrulhar" o código que você possui com o exigir incluir itens:

require(["jquery", "jquery.alpha", "jquery.beta"], function($) {
    //the jquery.alpha.js and jquery.beta.js plugins have been loaded.
    $(function() {
        $('body').alpha().beta();
    });
})

1
Eu realmente gosto do design do site. Eu nunca ouvi falar de requirejs. Como você classifica isso em solicitações HTTP? Isso não coloca mais solicitações de HTTP na página? (não é tão ruim assim?) Desculpe pelas minhas perguntas tolas.
Kyle

Ter menos solicitações é melhor, é claro, mas economizar> 350k também não é tão ruim. Sim, seu site fará mais uma solicitação se você incluir outra biblioteca nessa página. Se estiver datatablesem um site e jqplotem outro, tudo bem. Carregar mais cinco libs em 50% das páginas faria a vantagem desaparecer, eu concordo. Mas no seu caso, considero uma solução muito boa (supondo que o resto de vocês js permaneça um arquivo compactado em gzip).
Michael

Obrigado Michael. Esta solução é bastante brilhante. Antes de dividir tudo em uma página, mas isso ... Isso é melhor do que eu tinha em mente. Obrigado por esta sugestão. Como você conhece o requirejs, você acha que o requirejs seria suficiente? Eu vejo em alguns sites que eles usam o google para carregar seu jquery e outras bibliotecas google.load('...'),.
Kyle

1
Eu recomendo fortemente carregar bibliotecas comuns do Google (ou de outros sites que o ofereçam). Isso tem 2 vantagens: a) o arquivo lib é armazenado em cache entre sites diferentes. As chances são de que o usuário tenha visitado um site antes, que também usa o jquery carregado no Google. Este arquivo é então carregado do cache, não novamente do servidor! b) Mesmo que isso tem de ser carregado, ele será muito mais rápido para carregá-lo do Google CDN, do que de seu próprio servidor web.
Michael

8

Se sua estrutura / CMS / o que tiver as funções apropriadas, você poderá incluir os scripts condicionalmente, como sugere o @Michael, mas sem a biblioteca adicional.

Tomando seu caso de tabelas de dados, por exemplo, o WordPress pode lidar com a situação através de algo como:

// For reference; this isn't functional code.
if (is_page('whatever')) {
    <script src="/path/to/datatables.js"><script>
    <script>
        [Your datatables setup here]
    </script>
}

Não há nada errado com o RequireJS; você só precisa avaliar se o nível adicional de complexidade adicionado (além de aprender a usá-lo) compensa o que as ferramentas mais prontamente disponíveis podem fazer por você. Se você tiver apenas os dois casos mencionados acima, pode ser uma opção melhor. Se você tem muito mais em andamento, o RequireJS pode ser uma abordagem melhor em geral.


Eu tenho um site personalizado que criei a partir de um modelo html que comprei da themeforest. O único problema é que o cara tinha 6 arquivos JS espalhados e estava bagunçado. Então, eu os coloquei em um arquivo e isso inclui poucas bibliotecas jqplot, datatables, jquery-ui. Todos eles somam cerca de 550-600kb. 100kb é meu JS usando essas bibliotecas. Eu sinto que deveria corrigir isso em vez de carregar tantas bibliotecas JS irrelevantes em todas as páginas. Obrigado pela sua sugestão! =)
Kyle

5

700kb de JavaScript É um problema de desempenho, pois deve ser analisado após o carregamento da página. Por esse motivo, você deve tomar cuidado para que apenas os scripts necessários sejam carregados. Um grande JavaScript pode ser bom em sites AJAX completos, como o GMail, quando a navegação é realizada internamente sem sair da página única. No entanto, mesmo sites AJAX completos executam o carregamento dinâmico de JS para evitar o carregamento desnecessário de JS no início (emissão de memória e velocidade).

Você disse que queria reduzir o tráfego http. Você deve jogar com o cache HTTP . O problema é que as alterações no JS podem não estar visíveis até que o cache expire, se você definir o tempo de expiração muito alto.

Há um truque, no entanto, ao qual você não se refere myscript.js, mas myscript.js?version={myversion}. Após a atualização do aplicativo, você altera {myversion}e força o recarregamento do JavaScript.


Sim, com esse tamanho de JS, juntamente com o fato de serem principalmente bibliotecas bastante comuns, o uso de uma CDN será um grande benefício.
Zhaph - Ben Duguid

1

~ 700kb de JavaScript é um problema de desempenho e, se compactado, temos que ver as Regras a serem seguidas ao lidar com a otimização do Código:

  1. Minify Javascripts - Simplesmente você está compactando e descompactando, o que não reduziu o código. Primeiro, use a boa ferramenta Minify JS e minimize seu código. Você tem 12 arquivos e cada arquivo seria Minify sepratly antes da discoteca para obter o melhor desempenho.

  2. Use o carregamento assíncrono de javascript , usando o carregamento assíncrono resulta em um tempo de carregamento e renderização muito rápidos da página. O impacto do usuário é muito forte, porque um bom carregamento assíncrono não bloqueia o processo de renderização e o tempo de carregamento da página é muito reduzido. Imagens e outros itens exibidos regularmente serão mostrados como se nenhum javascript estivesse carregado.

  3. Use o GOOGLE cdn para JQUERY ; Acho que você está usando o JQUERY e carregando-o em seu próprio site, o que também é uma desvantagem adicional. Use o CDOG do GOOGLE (gratuito) para carregar o JQUERY. Como está sendo usado por quase todos os sites de terceiros e, portanto, já está disponível no computador-cliente em cache.

  4. Cabeçalhos de expiração longa personalizados : de alguma forma, como o site é carregado com a questão do tempo de carregamento, você deve fornecer os Expirações Longas para Arquivos JS HTTP, para que não possam ser baixados sempre, o que reduzirá a solicitação pela segunda vez. De acordo com minha pesquisa, o tempo de carregamento gasto na segunda página tem mais saídas em comparação com a primeira visita à página.

  5. Verificar com a velocidade da página : algumas vezes outros recursos também afetam a velocidade de carregamento da página, por favor, cruze a verificação e tente otimizar outros recursos também. Como dar um passo em cada recurso, dedique um tempo extra ao carregamento do JS.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.