Desempenho do servidor reflete diretamente no indice de satisfação do cliente pelo seu serviço, diretamente no Google, já que ele adora sites que sejam rápidos e a sua de ter uma aplicação rápida.
Primeira item a ser verificado é o servidor. O php-apc pode ajudar em muito. Também tem o eAccelerator e o XCache. Também o mod_deflate ajuda para que os códigos gerados chegem mais rápido até o cliente.
Utilize o NGINX para os assets (imagens, CSS e JS, SWF e tudo mais que for estático).
Mais esta tarefa também é do programador que deve gerar códigos que sejam executados mais rápidos pelo servidor.
Veja a seguir uma lista de testes:
Dica 1
require() é mais lento que o include() e o [require/include]_once é mais lentos ainda;
Mais continue usando o require que é mais confiável...
Dica 2
Sempre use caminhos absolutos ao chamar arquivos no require/include. Isso porque o PHP não precisará buscar e analisar o include_path;
// Ex: require( '/home/seusiote/public_html/classes/ClasseSeiLa.php' );
Imagine que seu servido tenha um include_path de várias pastas. Ele terá que testar em todas as pastas para ver se encontra o arquivo que você esta tentando carregar. Se ele possuir o caminho absoluto não precisará fazer nenhuma validação.
Dica 3
echo é mais rápido que o print;
Veja os testes: /code/10050/Captura de tela 2013-12-18 as 18.01.21.png
Dica 4
echo com parâmetros é mais rápido que echo com concatenação;
Dica 5
Aspas simples é mais rápido processar que aspas duplas;
// EX lento: echo "A variável seila possui o valor = $seila";
// EX rápido: echo 'A variável seila possui o valor = ' . $seila;
// EX mais rápido: echo 'A variável seila possui o valor = ', $seila;
Veja os testes: /code/10050/Captura de tela 2013-12-18 as 18.11.12.pdf
Dica 6
Evite calcular os tamanho dos elementos dentro do laço FOR.
// Ex Errado:
for( $i=0; $i<count( $array ); $i++ )
...
// Ex Certo:
$size = count( $array );
for( $i=0; $i< $size; $i++ )
...
Veja os testes: /code/10050/Captura de tela 2013-12-18 as 22.43.18.png
Dica 7
Métodos mágicos como o __autoload, __get, __set trabalham com erros do PHP e devem ser economizados ao máximo;
Dica 8
Usar o "@" em funções para evitar erros, além de ser POG é lento para o PHP. Se sabe que vai dar erro, valide antes;
Dica 9
Jamais use string sem aspas. Vejo que tem gente que programa assim: $array[coluna] e isso é muito lento ao PHP, visto que o PHP irá checar se o "coluna" é uma constantes antes de usa-lo como string. Ou seja, é POG.... Testes mostram que usando aspas o código é executado mais rápido:
// Ex errado echo $array[coluna];
// Ex rápido echo $array["coluna"];
// Ex mais rápido echo $array['coluna'];
Veja os testes: /code/10050/Captura de tela 2013-12-18 as 22.47.36.png
Dica 10
Variáveis locais são mais rápidas. Então se precisar alterar muitas vezes o valor de uma variável GLOBAL o faça apenas uma vês
// Ex lento
function seiLa() {
GLOBAL $teste;
for ( $i=0; $i<20; $i++ )
$teste .= "bla bla bla"
}
// Ex mais rápido
function seiLa() {
GLOBAL $teste;
$testeLocal = $teste;
for ( $i=0; $i<20; $i++ )
$testeLocal .= "bla bla bla";
$teste = $testeLocal;
}
Veja os testes: /code/10050/Captura de tela 2013-12-18 as 23.12.34.png
Dica 11
Evite ao máximo as aspas duplas. String com aspas duplas são processadas pelo servidor em busca de variáveis e caracteres especiais.
// Ex lento echo "<p style="width:10px;">teste sei la e só texto aqui</p>";
// Ex mais rápido echo '<p style="width:10px;">teste sei la e só texto aqui</p>';
Veja os testes: /code/10050/Captura de tela 2013-12-18 as 23.24.49.png
Dica 12
Você sabia que ++$var é mais rápido que $var++? Mais não tanto a ponto de valer a penas alterar seus códigos...
E sobre o servidor?
E, não se esquecendo que Windows para servidor JAMAIS: http://www.paessler.com/webstress/sample_performance_tests/comparing_php_script_performance_on_linux_and_windows
E compactar o HTML também ajuda?
php.eduardokraus.com/compactando-o-html-de-suas-paginas
Uma coisa que fui descobrir depois de fazer isso é que o uso do ob_start no início do arquivo também melhora a performance. O SO recebe o HTML de uma vês só e não precisa ficar compactando em partes pequenas. Também o Navegador o recebe em um todo e renderiza na tela em um todo, evitando que o faça em partes...
E o CSS?
Compactar o CSS faz com que ele chegue mais rápido até o cliente economizando banda e tempo de espera. php.eduardokraus.com/eu-vs-cache-ganhei-a-batalha.
Também estou começando a testar o uso do WEBP e do data-uri em CSS. data-uri para quem não sabe é usar a imagem embed no CSS, evitando uma requisição para cada uma das imagens. Cada requisição ao servidor, mesmo que seja do NGINX usa um pouco de memória, processamento, leitura do disco, etc...
Vale a pena usar WEBP sabendo que hoje só funciona no Chrome?
WEBP é um padrão Google, criado a partir do VP8. Algumas imagens chegam a ficar até 80% menores. Veja este https://www.cidadedesaobonifacio.com.br/img/top-center-bg.jpg.webp (28K) vs este https://www.cidadedesaobonifacio.com.br/img/top-center-bg.jpg (118K)
Sim, hoje mais de 50% dos acessos vem do Chrome e isso significa que 50% dos acessos são respondidos com uso do WEBP. Vale muito a pena, principalmente para quem paga CDN.
E agora?
Agora é a parte que você diz que eu sou louco em ficar calculando milisegundos. Mais de grão em grão a galinha enche o papo e é de milisegundos em milisegundos que eu tenho a economia final.
Banheiros estão vindo com aquela descarga só para xixi que pode não significar muito, mais no fim do mês a soma de tudo é muito. Então cada byte economizado é um byte a menos que precisarei pagar para os provedores, um byte a menos para trafegar, e um byte a menos para ser analisado pelo navegador e impactará em um pentelhésimo de segundo a menos que o browser necessítará para renderizar o site.