Guia completo: Como diminuir o tempo de carregamento do seu site

Como diminuir o tempo de carregamento do seu site

O tempo de carregamento é um dos fatores determinantes para saber se o usuário ficará ou não em seu site. Isto porque, se o site não carregar em um tempo razoavelmente baixo, o usuário simplesmente vai procurar o mesmo conteúdo em outros lugares, afinal de contas, a concorrência existe (e aos montes!). Além de prejudicar o site na questão acessos, a demora no carregamento completo do site contribuirá para rebaixamentos nos mecanismos de pesquisa e reduzirá ganhos publicitários em ferramentas como Adsense. Neste guia, será abordado de forma detalhada, como reduzir o tempo de carregamento de um site, através de configurações avançadas no servidor Web.

Antes de mais nada, vamos lembrar como começou a Internet aqui no Brasil.
A Internet veio com um certo atraso por aqui; praticamente, os primeiros acessos foram de universidades e Órgãos do Governo em 1994-1995. A partir deste momento e com a popularização do Windows 95, ficou claro a todos que o WWW veio para ficar. No início, a conexão brasileira era muito mais baixa em relação ao que temos hoje, mas em contrapartida, os websites também eram leves e simples, sem muitas animações ou imagens. Porém, como o passar dos anos, novas tecnologias foram sendo criadas, e a Internet foi se transformando no que temos hoje.

A Internet vem transformando o mundo em que vivemos

A Internet vem transformando o mundo em que vivemos

Tudo isso tem um preço. A conexão de Internet brasileira precisava (e ainda precisa, principalmente a conexão móvel 3G) ser melhor, para que o acesso a estes novos conteúdos seja feito com o menor tempo possível. E como todos sabemos, readaptar toda uma infraestrutura apenas para aproveitar websites na Internet não é viável (principalmente no Brasil), até mesmo para países como os EUA (que a propósito, utiliza fibra ótica desde 2000). A solução mais óbvia é fazer com que os websites sejam mais leves. E para que isso seja possível, foram criados vários padrões na indústria de navegadores e servidores web, a fim de reduzir a transferência de dados.

 

Por que um site deve ser rápido?

Além do óbvio, um site deve ser rápido para que a experiência do usuário seja a melhor possível. Considere o seguinte: Sabemos que boa parte dos sites recebem visitas do Google. Se um usuário acessa o seu site e este demora para carregar, o que ele faz? Volta aos resultados de pesquisa e procura em outro site. Isso é conhecido como Bounce Rate ou Taxa de Rejeição. Se a taxa de rejeição de um site é muito alta, significa que boa parte dos visitantes não estão satisfeitos com o site.

Sites rápidos são mais propícios a receberem visitantes

Sites rápidos são mais propícios a receberem visitantes

O Google deixa claro que os melhores sites devem aparecer nas primeiras posições, e isto é medido através de centenas de métricas, a maioria delas são desconhecidas. E velocidade do site vem sido tema de inúmeras palestras e artigos nos blogs oficiais da companhia. Tudo indica que, um site rápido é mais propício a receber visitantes, pois teoricamente, a experiência do usuário seria melhor em relação à um site que leva muitos segundos para carregar. Existem até pesquisas sobre isso:

Yahoo! descobriu que, para cada 400ms de melhora na performance, seu tráfego aumenta em 9% (fonte).

Ao cortar 2,2s da landing page do Firefox, a 
Mozilla aumentou o número de downloads em 15%, totalizando um ganho de mais de 60 milhões de cópias por ano (fonte).

Amazon concluiu que apenas 100ms de melhora aumentam 1% seu faturamento (fonte).

Em um de seus vários experimentos, o Google aumentou o número de resultados por página de 10 para 30. Isso aumentou o tempo de carregamento de 0.4s para 0.9s, o que diminuiu em 20% o tráfego das buscas (fonte).

Microsoft mostrou que 2s a mais de latência no Bing diminuíam o faturamento em 4,3% (fonte).
Trecho retirado do Blog Caelum.

 

Por que um site é lento?

Existem dezenas de causas que podem deixar um site lento, mas as principais estão diretamente relacionadas com o servidor. Quando alguém acessa um website, são abertas várias requisições ao servidor, para que sejam baixados os arquivos HTML, CSS, imagens, javascript e etc. Agora imagine 100 pessoas ao mesmo tempo, solicitando várias conexões ao servidor. Se o servidor não for adequado para o peso e o tráfego do site, o Server Load aumentará, deixando tudo mais lento.

 

Configurações Server-Side

O Servidor é um dos principais responsáveis por deixar um site lento ou inacessível. Falaremos detalhadamente as causas e soluções para manter um Servidor Web rápido e estável. Neste guia, abordaremos apenas o Servidor Web Apache em Sistema Operacional Linux.

 

Server Load

O processador do servidor está em iddle (repouso) quando a carga de processos em funcionamento é igual a zero. Quando o usuário acessa o site, são executados scripts server-side, onde o Servidor WEB faz o processamento, abrindo um novo processo (task) no processador (ou executando o mesmo processo persistente, no caso do Apache estar rodando como fastCGI, falaremos disso depois). Este processo demanda uma certa carga de processamento.

Caso sejam abertos vários processos simultâneos, o Servidor irá compartilhar parcelas do processamento para cada processo, tentando assim “processar tudo” ao mesmo tempo (multitarefa), porém, de uma forma mais demorada. E dependendo do caso, os processos vão ficando na lista de espera de processamento, enquanto novos processos vão sendo abertos e fechados. O resultado disto é, Server Load acima de 1.0 (100% de processamento).  Quando o Server Load começa a aumentar muito, acima de 5, não há mais nada a fazer senão reiniciar o Apache (service httpd restart), pois o processador ficará mais e mais lento.

Consultando o Server Load através do SSH, comando TOP

Consultando o Server Load através do SSH, comando TOP

A solução para o Server Load é investir em Servidores com mais processadores, ou um processador com mais núcleos de processamento. Assim, as tarefas serão divididas entre eles, evitando o Server Load acima de 1. Outra solução, é reduzir o número de processos através de Cache de Opcode (Cache de códigos server-side em Memória RAM, para evitar novas interpretações), Cache de navegador (com .htaccess) e principalmente, otimizar os códigos-fonte do site.

 

Apache suPHP x Apache DSO x Apache FastCGI

Existem várias formas de interpretar códigos PHP no servidor, conhecidas como Handlers. Para que o PHP seja processado, é necessário que o Apache execute os scripts como suPHP, DSO (mod_php) ou FastCGI. E qual a diferença entre os três Handlers?

  • suPHP é o Handler padrão da maioria dos servidores, inclusive padrão adotado pelo cPanel/WHM. No suPHP, é possível separar várias contas de usuários num mesmo servidor, sem que haja a vulnerabilidade de uma conta acessar a outra. Assim, é possível instalar uma revenda de sites, e cada conta com seu próprio usuário. Outra vantagem do suPHP, é a segurança, pois é possível executar os processos individualmente para cada usuário. Assim, não é necessário nem permitido usar permissões de risco em pastas e arquivos, como a CHMOD 777 ou 775. Dessa forma, um usuário não consegue acessar pastas e arquivos do outro, através de scripts server-side. O problema do suPHP é o alto uso de processamento, pois a cada nova requisição, é aberta um novo processo do usuário em questão no processador.
  • DSO é considerado antigo, porém é a melhor opção para usar em Servidores Web 100% dedicados. Este Handler executa todos os processos com o usuário nobody, exigindo permissões de risco como 777 para salvar arquivos. Apenas Servidores dedicados devem usar o DSO, pois como haverá apenas uma conta de usuário, não haverá problemas com as permissões de arquivos. A principal vantagem, fica por conta do menor uso de processador em comparação com o suPHP. A desvantagem do DSO, é não permitir o acesso direto a pastas e arquivos sem que a permissão máxima seja dada. Portanto, no caso do WordPress, não será possível atualizar automaticamente, nem instalar temas e plug-ins pelo painel.
  • FastCGI é a combinação perfeita do suPHP e do DSO, pois reúne a segurança do suPHP ao criar os processos individualmente para cada usuário e usa menos processamento, reduzindo assim o Server Load. O FastCGI é recomendado em Servidores Semi-dedicados, também conhecidos como VPS ou em Servidores dedicados. A única desvantagem é o alto uso de Memória RAM, pois para manter a velocidade de processamento, o FastCGI salva em memória alguns processos rotineiros (MySQL por exemplo), para que sejam abertos novamente quando solicitados. Na prática, o FastCGI trabalha com processos persistentes rodando em Memória RAM. Outra vantagem, é a possibilidade de fazer Cache de PHP com OpCodes (xCache, APC, Memcached, eAccelerator, Zend Optimizer+ e etc) , salvando variáveis, Arrays, Resources e até scripts inteiros em Memória, para que não seja necessário processar novamente o mesmo script. Isto é uma grande vantagem, especialmente em sites em que o processamento é sempre o mesmo, como Fóruns, Blogs e etc.

O BLog Lucas Peperaio usa o FastCGI, pelas vantagens de segurança do suPHP e a performance do DSO. Ao usar o suPHP, chegamos em determinados momentos ao Server Load 50, já com o FastCGI, dificilmente passa de 1, porém, o uso de memória é maior, como foi falado. O Blog está hospedado em um servidor semi-dedicado, com um processador Intel Xeon de dois núcleos e 2GB de Memória, suficiente para segurar mais de 800 usuários online.

Uma tabela rápida sobre os Handlers:

DSO SuPHP FastCGI
Baixo uso de processador
Baixo consumo de memória
Executa o PHP individualmente para cada usuário
Segurança no caso de múltiplos usuários

Se você têm a disposição o WHM/Cpanel em seu servidor (válido apenas para usuário Root), poderá alternar entre os Handlers de uma forma muito simples. Basta recompilar o Apache em SoftwareEasyApache. O processo durará de 30 a 60 minutos.

Easy Apache - Recompilar o Apache para alternar entre os Handlers

Após isso, alterne o Handler como preferir em Service Configuration > Configure PHP and suEXEC.

Alterando os handlers php no WHM

Considerações finais sobre os Handlers: Se você possui um Servidor Dedicado com apenas um usuário, o DSO é perfeito para você. É incontestável a rapidez oferecida com o baixo uso de processador. Já em um Servidor com mais de um usuário, seja dedicado ou semi-dedicado, o recomendado é o FastCGI. Não recomendo usar o suPHP pelo alto uso de processamento.

 

Módulos do Apache para otimizar a performance

Após a escolha do Handler adequado, vamos habilitar e configurar uma série de módulos do Apache, para obter a máxima performance do Servidor. Entre eles, estão alguns módulos responsáveis por permitir um controle de Cache mais preciso, outros para comprimir o conteúdo antes de enviar ao usuário e etc.

Mod_deflate

Com o Mod_deflate, é possível comprimir arquivos HTML, CSS, Javascript e até imagens, antes que seja enviado ao usuário. Dessa forma, o navegador do usuário baixará os arquivos do site com um tamanho até 70% menor, reduzindo consideravelmente o tempo de carregamento. O Apache compacta o conteúdo usando Gzip, e envia um cabeçalho “Content-Encoding: Gzip ou Deflate“, indicando que os arquivos estão sendo compactados. Detalhe importante, o Mod_deflate é o sucessor do Mod_gzip, que é antigo e não deve ser usado.

Para usar o Mod_deflate (é preciso instalar ou habilitar o módulo primeiro no Servidor), inclua as seguintes regras no .htaccess:

<IfModule mod_deflate.c>
   <FilesMatch "\.(js|css|jpg|png|gif|ico|php|html|htm)$">
     <ifModule mod_filter.c>
       SetOutputFilter DEFLATE
       AddOutputFilterByType DEFLATE text/css text/javascript application/x-javascript text/html text/plain text/xml image/x-icon
     </IfModule>
   </FilesMatch>
</IfModule>

Veja nas imagens abaixo, a comparação de dois acessos, um com o Servidor enviando os arquivos compactados, e o outro com os arquivos sem a compactação. A redução foi maior que 100%.

Requisição sem compactação Gzip

Requisição sem compactação Gzip = 289 KB

Requisição com compatação Gzip

Requisição com compatação Gzip = 131,6 KB

Mod_headers, Mod_expires

Com os módulos Mod_headers e Mod_expires, é possível ter um controle mais apropriado sobre Cache de navegador. Cache é um recurso muito útil para reduzir o tempo de carregamento, pois é possível salvar na máquina do usuário todo tipo de conteúdo estático, como imagens, css, html e etc. Dessa forma, o navegador não precisa solicitar ao Servidor estes recursos, e sim solicitar ao Cache, acelerando (e muito) o tempo total de carregamento. Para mais informações sobre Cache, leia este artigo completo: Cache de Navegador com .htaccess

 

Configurações do Apache para otimizar a performance

O Apache é o Servidor Web mais utilizado do mundo, devido a sua facilidade, rapidez, estabilidade e imensa quantidade de módulos e configurações extras. Porém, podemos configurá-lo para rodar com máxima performance e com milhares de conexões simultâneas. Todas as configurações podem ser feitas no WHM ou diretamente no arquivo httpd.conf. Vejamos:

Keep-Alive

O Keep-Alive é uma configuração do Apache que permite conexões persistentes para um usuário. Quando um usuário acessa um site, são feitas várias conexões TCP para os diversos arquivos a serem baixados. Com o Keep-Alive, o cliente executa apenas uma conexão TCP, e esta fica aberta por um determinado tempo (configurável no Apache em Kepp-Alive Timeout). Isso aumenta a velocidade de carregamento do site e a velocidade do servidor (reduzindo o número de conexões, o Server Load também é reduzido). Porém, o Keep-Alive causa um aumento de memória, pois as conexões ficam abertas (geralmente por alguns segundos ou quando atingir o número máximo de requisições, configurando em Max Keep-Alive Requests) esperando o uso do cliente. Portanto, se o Servidor tiver uma boa quantidade de Memória RAM, ative o Keep-Alive.

Server Tokens

Em cada requisição feita ao Apache (Request), é enviada uma resposta (Response) com os cabeçalhos necessários. No entanto, o Apache envia por padrão o seu nome, versão e alguns módulos instalados em todas as requisições, como pode ser visto na imagem:

Response Headers com cabeçalho desnecessário

Cabeçalho desnecessário, que torna a requisição maior, consequentemente, mais lenta.

Note que em Server, é passado a configuração completa do servidor, algo totalmente desnecessário e inclusive, uma brecha de segurança, pois informa à qualquer um a versão do Apache, PHP, Sistema Operacional e etc. O ideal então, é configurar para que apareça o mínimo possível, reduzindo o tamanho da requisição, marcando a opção Product Only. As novas requisições ficarão assim:

Informações descessárias removidas

Informações descessárias removidas, consequentemente, a requisição fica menor, reduzindo o tempo de carregamento do site

Requisições desnecessárias

Em Response Headers padrão, é enviado o Content-Language do arquivo (ver imagem acima). No entanto, imagens não precisam de Content-Language, o que a torna um pouco mais pesada. O ideal é retirar este cabeçalho em imagens, criando uma simples regra no .htaccess:

<IfModule mod_headers.c>
   <FilesMatch "\.(ico|jpg|jpeg|png|gif)$">
      Header unset Cookie
      Header unset Set-Cookie
      RequestHeader unset Cookie
      FileETag Mtime size
      Heder unset Content-Language
   </FilesMatch>
</IfModule>

Note que na mesma regra, estamos retirando o Cookie das imagens, que muitas vezes é desnecessário. Retirando a linguagem e os cookies, as imagens serão baixadas mais rapidamente.

 

Configurações do PHP para otimizar a performance

Segundo pesquisas, páginas em PHP demandam de 5 à 10 vezes mais processamento, memória e tempo do Servidor do que páginas em HTML puro. Então, sempre que for possível, use páginas apenas com HTML (sem códigos server-side). Como isso nem sempre é possível, usaremos PHP, porém, da melhor forma possível. Para isso, é necessário antes engolir guela abaixo este artigo do Google: PHP Performance Tips. Após essa breve refeição, vem a sobremesa: 63+ Best practice optimize PHP code performance.

Considerando que você leu ambos os artigos e já otimizou o seu código PHP, vamos ressaltar outras três otimizações:

OpCode (Apenas para Handler FastCGI)

Scripts PHP precisam ser interpretados e processados a cada vez que são acessados, e como falamos, este procedimento é altamente custoso ao Servidor. Para diminuir a carga do processador, foram criados diversos “aceleradores de PHP”. Cito um dos mais utilizados, APC (Alternative PHP Cache), que é mantido pela comunidade do PHP (portanto está sempre atualizado e otimizado). Inclusive, o próprio criador do PHP trabalha neste projeto.

Um OpCode salva certas informações, determinadas pelo desenvolvedor, em Memória RAM. Estas informações podem ser variáveis,  Arrays, Resources e etc. Assim, quando o Script for solicitado novamente, ao invés de ser processado novamente, será obtido da memória. O desempenho chega a aumentar até 20%, dependendo do caso.

O APC é um módulo PECL, portanto é preciso baixá-lo e compilá-lo no PHP. Pelo WHM, acesse a opção Module Installers e procure por APC, conforme na imagem abaixo. Caso não disponha do WHM, ainda é possível instalá-lo manualmente, via SSH (linha de comando).

Instalando APC Cache no WHM

Instalando APC Cache no WHM

PHP Flush()

Quando você abre um Web Site em seu navegador, é enviada uma solicitação ao servidor onde ele está hospedado, para que comece o processamento e o seu posterior envio. Entretanto, há um pequeno delay, um tempo de espera entre esta solicitação e este envio, geralmente de 200 a 500ms. Enquanto isso, o navegador fica aguardando a página carregar…

Com o PHP Flush(), o servidor envia uma resposta parcial para o navegador, mesmo antes de carregar completamente e completar o envio. Assim, enquanto o servidor está processando a página a ser enviada, o navegador já começa a montar a página HTML, reduzindo então no tempo de carregamento total da página.
Leia o artigo completo sobre PHP Flush().

ob_gzhandler

O Buffer de saída PHP também pode ser compactado com Gzip, através do callback ob_gzhandler em ob_start(). Desta forma, antes de enviar o Output ao navegador, o PHP irá comprimir a saída e enviar o cabeçalho Content-Encoding: Gzip ou Deflate.

Existem várias outras configurações avançadas no Apache, como Max Clientes, Start Servers, Prefork. Assim como existem diversas técnicas que otimizam no Cliente-Side, ou seja, configurações feitas no site. Evitamos falar sobre isso, pois existem inúmeros artigos ensinando como otimizar a performance também no Cliente, como o famoso guia do Yahoo! -> Best Practices for Speeding Up Your Web site. Enjoy!

Dúvidas, deixe nos comentários!
Fonte: Apache, PHP, BoomShadow

Lucas Peperaio

Estudante de Ciência da Computação, trabalho com desenvolvimento web há 5 anos e com hardware há 8. Nas horas vagas, sou entusiasta de Overclock, Casemod e Benchmarks, além é claro dos Games. Apaixonado por informática e pela vida, procuro compartilhar meus conhecimentos e assim, ajudar as pessoas. Siga-me no youtube, posto semanalmente muito material sobre Hardware, tecnologia e games em geral: Clique aqui

Receba gratuitamente em seu E-mail
Novos artigos do meu Blog!


Após o Cadastro você receberá um Email Automático. Clique no link enviado para Ativar e receber as novidades.

Categorias do site





11 Comentários Deixe o seu

  1. Blog Programação

    Que excelente artigo! Muito completo mesmo, obrigado por compartilhar toda essa informação.

    Gostaria de acrescentar que existe a proposta do protocolo SPDY para melhorar o HTTP e encurtar o tempo de latência de rede nas requisições HTTP.

    O navegador Chrome já vem usando SPDY com Gmail e nas buscas Google. Talvez por isso as pessoas achem o Chrome mais veloz para serviços Google. Vale a pena experimentar.

    Abs. Literati

  2. Direitos Trabalhistas

    É justamente o que eu preciso. Porém sou iniciante nesse assunto, prefiro não arriscar.

    • Lucas Peperaio

      É praticando que se aprende! E na pior das hipóteses, o WHM tem função de backup/restore.

  3. Eduardo

    Parabens, excelente postagem, tenho uma empresa de e-commerce e atua a tempos no mercado e a sua explicação foi perfeita, parabens

    Abs Eduardo

  4. Fabio

    Olá Lucas.. Primeiramente parabéns pelo artigo e pela iniciativa.

    Gostaria de saber sua opinião sobre o trabalho do Fast CGI com MPM Prefork e Worker. Qual seria a melhor escolha? Teria alguma dica de configuração para turbinar o apache baseado nesta escolha? Obrigado!

  5. Bruno

    Olá,

    Parabéns pelo artigo!

    Só fiquei com uma dúvida, como eu faço para marcar a opção “Product only” para as requisições? Qual o código pra isso?

    Obrigado

  6. Anderson camargo

    Excelente artigo voce poderia indicar uma hospedagem de qualidade

  7. leandro

    como sempre vc se superando, otimas explicaçoes

  8. Edi

    A publicação é antiga, mas é muito boa. Porém depois de ler tudo e achar interessante, resolvi testar seu próprio site no PageSpeed e tem um tempo de resposta de 54ms. Eu estou querendo reduzir o meu que é de 22ms. O que eu faço?

  9. paulo robson

    Excelente post Lucas, Deus te abençoe.

    Ficou bem completo e detalhado vlw

  10. everton

    Muito bom seu artigo! Peguei estas dicas pra usar no meu site! obrigado!