Traduzido do 日本語 • Ver original Este é um memorando de quando eu estava construindo um site multilíngue com WordPress, e eu estava fazendo ajustes de desempenho para todo o canteiro de obras quando o teste de integração estava quase terminando.
O site-alvo não era tão grande, então eu estava construindo em uma instância AWS m3.medium, mas o desempenho geral do site caiu desde o meio do desenvolvimento, e ele se tornou um site muito pesado. Verificação de desempenho do site Olhando o relatório sobre o "GTmetrix", o único resultado é que a resposta das imagens usadas no site é a latência, e por enquanto, otimizamos as imagens o máximo possível, e o desempenho do front-end melhorou consideravelmente, mas a tela de gerenciamento do WordPress continuou pesada. No lado do servidor web, compressão GZIP de conteúdo estático, . Tentei várias medidas, como migrar configurações para httpd.conf sem usar . Também tentei verificar e ajustar as configurações do banco de dados com o MySQLTuner, mas não houve mudança.
Hmm~mm, se você olhar para o CloudWatch, o uso da CPU é extremamente grande, então pode ser devido à incompetência da instância da AWS... Nesse caso, pode ser necessário mudar a instância da instância m3.medium para o sistema c3 no final... Eu estava pensando nisso, mas deve haver um fator fundamentalmente diferente: a tela de gerenciamento é pesada no site em desenvolvimento e é acessada por apenas algumas pessoas na empresa. A única coisa relacionada ao site inteiro é o tema ou o plugin. Então, quando testei o desempenho do plugin que estava apresentando, encontrei que era ótimo! … A causa da queda de desempenho foi o plugin.
Desta vez, usamos o "P3 (Plugin Performance Profiler)" para verificar o desempenho do plugin. É estranho incluir outro plugin para verificar o desempenho de um plugin, mas esse plugin P3 é excelente para escanear e reportar o desempenho de plugins e temas no seu site WordPress até o menor detalhe. É fácil de instalar e, uma vez que você baixa e ativa o plugin, sempre pode escanear o desempenho na seção "Tools" do menu de administração.
O resultado da digitalização com este plugin P3 é o seguinte.
Você pode ver que o plugin multilíngue "Polylang" e o plug-in personalizado de tipo de post "Types" estão pressionando o tempo de execução. Como esperado, por ser um site multilíngue, "Polylang" não pode ser omitido, mas muitos plugins de tipos de posts personalizados são substituíveis porque existem muitos plugins semelhantes. "Types" é um plugin que oficialmente suporta "Polylang", então eu o usei, mas não é fácil de usar porque consome muito tempo de execução só por estender o post personalizado.
Por isso, removi o plugin "Types" e introduzi o plugin "Custom PostType UI", que conheço no mesmo sistema.
O tempo de execução ocupado pelos "Tipos" foi eliminado, e o tempo de carregamento e o impacto do plug-in foram melhorados. A velocidade percebida da tela de gerenciamento também foi melhorada dezenas de vezes, e a experiência original que permitia edição nítida foi restaurada. Percebi que um único plug-in pode mudar muito o desempenho... Pude perceber isso.
A partir desse incidente, pessoalmente pensei que, ao criar um site WordPress no futuro, seria melhor focar no desempenho do que na funcionalidade do plugin. Isso porque você pode adicionar quantas coisas quiser depois que faltam na funcionalidade do plugin, mas é muito difícil modificar o desempenho que depende do núcleo do plugin.
Em particular, se a tela de gerenciamento for pesada, a motivação da pessoa da web responsável por operar o site vai cair consideravelmente, então acho que seria mais agradável ter uma tela de gerenciamento que possa ser operada sem estresse, mesmo que falte um pouco de funcionalidade.