- Detalhes
- Ribamar FS By
- Categoria: Desempenho
- Hits: 127
Performan em sites Joomla
Por
Nicholas K. Dionysopoulos
Em 5 partes:
Origiais em inglês
https://www.dionysopoulos.me/joomla-performance-tuning-i-start-at-the-beginning.html
https://www.dionysopoulos.me/joomla-performance-tuning-ii-basic-settings.html
https://www.dionysopoulos.me/joomla-performance-tuning-iii-static-media-optimization.html
https://www.dionysopoulos.me/joomla-performance-tuning-iv-site-building-calisthenics.html
https://www.dionysopoulos.me/joomla-performance-tuning-v-content-quality.html
Quinta e ultima parte
Joomla Performance Tuning V: Content Quality
Feliz Ano Novo 2021 a todos! Esta é a última parte da minha série sobre otimização de sites Joomla. Na edição anterior fizemos alguns exercícios de construção de sites. Hoje falaremos sobre conteúdo. Este não é necessariamente um tópico do Joomla – aplica-se igualmente ao WordPress, Drupal, Medium, Blogger e tudo que publica palavras escritas na web.
Você já pensou que o próprio fato de eu poder fazer com que dados incorpóreos sejam transferidos por todo o globo usando movimento de elétrons e luz, para que uma rocha pensante alimentada por relâmpagos possa renderizar alguns rabiscos em um pedaço de vidro que farão você ter alucinações? copiar meus pensamentos em seu cérebro não é nada mágico?
É disso que se trata a web. Magia prática, projetada para comunicar nossos pensamentos a pessoas que possivelmente nunca conhecemos e com quem nunca teríamos a chance de conversar. Sob esta luz, os sites são ferramentas de comunicação e a otimização de mecanismos de pesquisa (SEO) é um meio para um fim, não um objetivo em si. SEO tem como objetivo ajudar mais pessoas a encontrar nossos pensamentos.
Vamos falar sobre como podemos fazer isso de uma forma que faça sentido para nossos leitores, para nós mesmos e para as pedras mágicas do pensamento que pesam nossas palavras e decidem quais cérebros infectar com elas.
Divida artigos longos
Eu sei que sou culpado de escrever conteúdo muito longo. Meus artigos normalmente têm poucos milhares de palavras. A partir de um certo ponto, tornam-se demasiado onerosos tanto para os humanos como para as máquinas que os consomem.
Se seus artigos tiverem mais de alguns parágrafos, será útil colocar títulos neles. Os títulos funcionam como âncoras para o leitor, tanto na primeira vez quanto no que retorna. Falando em âncoras, se você quiser vincular a títulos específicos, lembre-se de fornecer atributos de id a eles. Admito que não faço isso com frequência em artigos. Eu, no entanto, pratico isso ao escrever documentação.
Os títulos só o levarão até aqui. Depois de chegar a algumas páginas impressas, seu conteúdo se torna muito longo para ser assimilado por um ser humano. É melhor dividi-lo em grupos lógicos desses títulos e colocar cada um deles em uma nova página.
Você não precisa e não deve criar um novo artigo para cada página! Joomla possui um recurso integrado de paginação de artigos. Use o botão Editor de quebra de página para separar suas páginas lógicas. Joomla mostrará um índice no topo de cada página e links para a página anterior e a próxima do seu artigo.
Mantenha o tamanho do DOM sob controle
Todo o seu site e seu conteúdo são entregues como HTML ao navegador. HTML é texto estruturado. Cada tag cria um nó na árvore Document Object Model (DOM), a representação interna do HTML analisado na memória do seu navegador. OK, tecnicamente é mais complicado do que isso, mas esta é uma boa aproximação para começar.
Um DOM aninhado muito grande ou excessivo causará problemas ao renderizar seu site. O navegador precisará despender mais esforço para organizar sua página. As interações com a página exigirão que o navegador recalcule um grande número de nós DOM. Suas páginas demorarão para carregar, exibir, rolar e interagir, enquanto consomem muito mais energia. Se é provável que o seu conteúdo seja consumido por 9 em cada 10 pessoas em um dispositivo móvel de baixa potência, você deve levar isso em consideração.
Você pode manter o tamanho do DOM baixo de pelo menos duas maneiras. Primeiro, divida artigos longos em páginas conforme explicado acima. Em segundo lugar, preste atenção ao seu HTML! Não use estilos embutidos, use classes. Provavelmente, seus estilos embutidos serão algo que você reutilizará e, de qualquer maneira, se sairá melhor como uma classe CSS. Não cole diretamente do Word ou de outro site. É melhor colar como texto simples e gastar um pouco mais de tempo reformatando seu conteúdo do que acabar com um ninho de tags e classes CSS sem sentido.
Em relação ao aninhamento do DOM, é algo que começa com o seu template. Tente organizar seu template de maneira sensata, sem muitas tags aninhadas. Isso pode aumentar um pouco suas habilidades em CSS. Eu deveria saber. Não sou exatamente uma autoridade líder na criação de uma estrutura de página em CSS do nada. Sempre que eu tinha que fazer algo que normalmente exigiria o uso de meia dúzia de tags CSS aninhadas, eu perguntava à minha esposa e ela apresentava uma solução que a princípio parecia magia negra, mas depois que eu dissequei seus componentes, ela fez um ótimo negócio de sentido. Flexbox e CSS Grid são seus amigos na criação de layouts poderosos, pois são fáceis de entender pelo navegador e por você mesmo. Essas coisas são mágicas. Se você não gosta de escrever CSS do zero, você pode usar o Bootstrap 4 que, diferentemente de suas versões anteriores, é um wrapper um pouco mais amigável em torno do Flexbox.
Ei, puristas: eu sei que o Bootstrap 4 é pesado, blá, blá, blá. Lembre-se de que a maioria das pessoas que lêem este artigo está tentando criar sites com uma equipe pequena, com prazos impossíveis e orçamentos apertados. Perder 10 pontos no Farol não é o fim do mundo. Não entregar um site a tempo também pode ser.
Escreva principalmente para humanos, não para bots
Muitos dos conselhos que você encontrará sobre como escrever um bom conteúdo para a web concentram-se em objetivos de curto prazo. Normalmente, ele diz a você como fazer com que os mecanismos de pesquisa classifiquem seu conteúdo de forma elevada, pelo menos no curto prazo, com total desconsideração de como os humanos percebem o resultado final. Para alguns sites, como campanhas de marketing por tempo limitado, isso faz sentido e, se você tiver um site assim, continue fazendo isso. Para a maioria dos sites, entretanto, esta pode ser uma abordagem míope.
Os mecanismos de pesquisa podem classificar seu conteúdo de maneira elevada e colocá-lo diante de mais olhos, mas isso não significa nada se não levar a mais tráfego em seu site. Um ser humano que já visitou seu site antes e o achou cheio de bobagens irá ignorar seus preciosos resultados de pesquisa altamente classificados quando estiver procurando por outra coisa. Os humanos se lembram mais das experiências ruins do que das boas. Esta é uma característica fundamental da natureza humana, que manteve vivos os nossos antepassados primitivos – aprender a evitar a caverna com o urso faminto foi uma habilidade fundamental de sobrevivência.
A melhor abordagem para o seu conteúdo é escrevê-lo da forma que for mais atraente para o público-alvo. Meu conteúdo, por exemplo, se enquadra em duas categorias aproximadas: artigos técnicos de instruções e artigos de opinião como este aqui. Eles têm públicos distintos com necessidades diferentes e expectativas. Meus artigos técnicos concentram-se no que você deve fazer, com uma breve descrição do porquê e uma explicação mais longa de exatamente como, o que está claramente marcado como tal. Eles são dispostos na ordem em que você precisa fazer as coisas. Advertências são apontadas. Muitos títulos ajudam você a encontrar seu lugar caso esteja perdido. A escrita é seca, técnica e direta.
Meus artigos de opinião são uma história diferente. Meu texto de introdução começa com um pequeno gancho que servirá como um bom resumo no cartão de link quando compartilhado nas redes sociais. Eu uso imagens atraentes pelo mesmo motivo. No texto completo começo com um parágrafo que define as expectativas e o tom. Tento empregar uma narrativa coesa, cada seção se baseando no que já abordei. Termino com um outro parágrafo que gentilmente leva o leitor de volta ao aqui e agora e o estimula a pensar mais sobre meu conteúdo. O conteúdo em si é escrito no mesmo tom informal que eu usaria ao fazer uma apresentação.
Descubra quais são as expectativas do seu público e module seu tom de voz e estrutura de conteúdo para atraí-los. Evite o que seria melhor descrito como “linguagem dura”, ou seja, formalidade excessiva – a menos que você seja um advogado ou esteja escrevendo um comunicado de imprensa para o primeiro-ministro, caso em que isso não pode ser evitado. No outro extremo do espectro, e a menos que o seu público espere explicitamente esse tipo de conteúdo, evite jargões, gírias e coloquialismos excessivos. Evite o verbalismo; sua erudição não é questionada ao escrever conteúdo para a web. Eu entendo a ironia de dizer a você para não usar palavras complicadas usando palavras complicadas; foi intencional e demonstra como o conteúdo fora do tom pode fazer com que seus leitores façam uma pausa. Finalmente, evite "fluff", ou seja, dizer algo simples com muitas palavras. Se o seu conteúdo parece ter sido escrito por um aluno entediado tentando atingir o limite de palavras, você perde credibilidade.
Verificação ortográfica e gramatical
Sempre verifique se há erros ortográficos e gramaticais em seu conteúdo. Ninguém espera que você esteja no nível de um linguista, a menos que você seja um, mas faça um esforço para evitar erros flagrantes.
A maioria dos navegadores e sistemas operacionais modernos inclui dicionários e corretores ortográficos integrados. Estou usando o Safari para escrever este conteúdo. Tudo o que preciso fazer para verificar a ortografia e gramática do meu conteúdo é clicar com o botão direito nele, clicar em Ortografia e Gramática e fazer com que ele identifique meus erros e faça recomendações.
Além disso, você pode usar recursos de terceiros, como Grammarly e Thesaurus, para melhorar sua redação. Você também pode tentar se casar com um americano que seja um defensor da gramática adequada, como eu fiz, mas recursos de terceiros são muito provavelmente muito mais práticos. (Ei, Crystal, se você está lendo este conteúdo, por favor, não me dê um F.)
Minimize interrupções
Além do tom e da estrutura do conteúdo, você deve evitar interrupções desnecessárias no fluxo de leitura do visitante. Não coloque anúncios em seu conteúdo. Se necessário, reduza-os ao mínimo e marque-os claramente como tal com dicas visuais sutis (como um fundo mais opaco ou uma borda leve). Evite anúncios grandes, em movimento, piscantes, visíveis ou pop-up, popover e pop-under. Eles são extremamente hostis para pessoas com deficiência cognitiva, epilepsia ou TDAH como o seu. Eu uso um bloqueador de anúncios agressivo porque esse tipo de anúncio impossibilita que eu me concentre no conteúdo. Não use anúncios que pareçam fazer parte do seu conteúdo ou do seu site, pois eles estão confundindo os visitantes e é provável que fechem a guia porque o seu conteúdo de repente não faz mais sentido. Não use anúncios que aparecem magicamente quando as pessoas rolam a página. Eles interrompem o fluxo de leitura e desencadeiam uma resposta de fuga. Pelo amor de tudo o que você ama, em nenhuma circunstância associe palavras aleatórias a anúncios. Quando as pessoas veem um link, elas esperam algo útil, e não uma bobagem completa.
Não use vídeo de reprodução automática, a menos que seu conteúdo seja apenas vídeo, claramente marcado como tal e que seus usuários esperem que ele comece a ser reproduzido. Muitos de nós temos filhos pequenos tentando dormir e ficamos ao telefone enquanto eles dormem, um processo que pode levar mais de uma hora regularmente. A reprodução automática de vídeos pode fazer com que nossos telefones comecem a emitir sons e acordem a criança. A maioria dos pais tem uma opinião muito forte sobre isso, a tal ponto que seria ativamente prejudicial para sua segurança física estar na mesma sala que eles, uma vez que você se identifique como a fonte daquele vídeo de reprodução automática. Reações semelhantes ocorrem quando nosso parceiro está dormindo, estamos no escritório (quando podemos voltar aos nossos escritórios depois que a pandemia estiver sob controle...), na estação de trem (idem) e assim por diante. Mesmo quando estamos sozinhos, aqueles malditos vídeos de reprodução automática são inesperados, irritantes e nos fazem nunca mais querer visitar seu site.
Na mesma nota, por favor, não exagere com pop-ups e popovers. Não quero seus biscoitos, ponto que já falei. Não quero assinar seu boletim informativo, acabamos de nos conhecer. Eu não me importo com o desconto que você jogou na minha cara; Ainda não li sobre a descrição do seu produto, com certeza não vou comprá-lo só porque você acenou com um desconto de 5% na minha cara. Não, você não tem permissão para me bloquear porque estou acessando seu site da União Europeia, você está fazendo errado o GDPR. Ah, pelo amor de Deus, não vou desativar meu bloqueador de anúncios para ler seu conteúdo; seus anúncios piscando impossibilitando o acesso ao seu conteúdo é o motivo pelo qual estou usando-o em primeiro lugar. PARAR. COM. O. POPUPS. *fecha a aba* Essa é minha experiência típica ao visitar um site atualmente. Se você criou um site assim, eu te odeio. A maioria das pessoas odeia você. Você está prestando um péssimo serviço ao seu público e, efetivamente, a si mesmo.
Resumindo, reduza ao mínimo as distrações desnecessárias. Seu público apreciará uma experiência livre de distrações. Faça anúncios sutis se é isso que está pagando suas contas. Ofereça seus boletins informativos como uma ação na barra lateral ou um anúncio in-line no final do seu conteúdo - se eu gostar, sim, posso até assinar seu boletim informativo para obter mais informações. Mostre-me o desconto do cliente pela primeira vez quando eu for para a página de compra do produto, não para a página de descrição do produto. Agradecerei, ainda mais se for um botão que o aplica para mim em vez de tentar copiá-lo para o meu smartphone, o que invariavelmente faz com que desapareça da minha vista. Respeite minha privacidade e minha decisão de usar um bloqueador de anúncios. Se precisar restringir meu acesso à quantidade de conteúdo que posso consumir, faça isso; O New York Times faz isso e eu ainda visito o site deles.
Torne seu conteúdo compatível com bots da mesma forma
Conteúdo de boa qualidade que agrada aos humanos em um site de carregamento rápido tem uma classificação muito boa nos mecanismos de pesquisa. É também muito mais provável que seus visitantes o compartilhem, o que criará ainda mais links de entrada para você, o que melhorará ainda mais a classificação. É como se os mecanismos de pesquisa tentassem mostrar aos usuários o conteúdo mais relevante e de fácil leitura, relevante para sua pesquisa...
Sarcasmo à parte, existem algumas coisas que você pode fazer para ajudar ainda mais os mecanismos de pesquisa e as plataformas de mídia social a digerir seu conteúdo e entendê-lo: microdados. Esses são atributos adicionais em seu conteúdo HTML que indicam o tipo de seu conteúdo e fornecem contexto adicional. Por exemplo, você pode dizer às máquinas que ingerem seu conteúdo quem é o autor, quando ele foi criado e modificado pela última vez, de que tipo de produto você está falando e onde encontrar mais informações sobre ele e assim por diante.
Joomla possui suporte integrado para microdados usando a linguagem Schema.org. Ela fez sua primeira aparição como uma biblioteca principal em 2013 para uso por plug-ins de terceiros e foi totalmente integrada à saída HTML dos componentes principais por volta de 2017. Se você tiver um terceiro, verifique se as substituições de modelo incluem microdados. Tudo o que você vê na aba Publicação ao editar um artigo passa a fazer parte dos microdados.
Falando na aba Publicação, lembre-se de preencher as informações do seu conteúdo. As meta palavras-chave não são mais as únicas dicas para um mecanismo de pesquisa, mas ajudam na desambiguação se não tiverem certeza sobre o contexto do seu conteúdo. A meta descrição raramente é mais usada nos resultados de pesquisa, ou nunca, mas muitos sites de terceiros a utilizam para apresentar um resumo do seu conteúdo quando há um link para ele. Os direitos de conteúdo são uma informação frequentemente esquecida, mas importante, que dá uma dica às máquinas e às pessoas sobre o licenciamento do seu conteúdo e se ele pode ser reutilizado.
Seus links para recursos externos devem ter um atributo rel definido como nofollow para quaisquer links que apontem para algo que você não endossa ou que seja de natureza comercial. Se você estiver vinculando a páginas internas que não devem ser indexadas, como uma página de carrinho ou checkout, um painel de usuário, etc., você deve definir o atributo rel como noindex.
Isso é tudo, pessoal!
Esta série de artigos foi uma jornada selvagem para mim. Comecei a trabalhar para melhorar o desempenho do meu blog em abril. Eu estava trabalhando nisso até julho. Acabei escrevendo vários plug-ins e fazendo muitas mudanças, grandes e pequenas, em todo o site. Nasceu a necessidade de compartilhá-lo com o mundo.
Comecei a escrever esta série no final de julho de 2020, pensando que seria um artigo único e bastante longo. À medida que continuei escrevendo, acrescentando coisas novas e revisando o que já havia escrito, percebi que ninguém teria paciência para ler um artigo de 13.000 palavras – a maioria das pessoas chamaria de livro pequeno. Comecei a reorganizá-lo em novembro como uma série de artigos, com a intenção de publicá-lo como meu calendário do advento em dezembro. Caro leitor, eu deveria saber melhor.
Entre meados de novembro e o Natal, fiquei preso no trabalho. Todos se encontraram com uma pressa louca para fazer tudo o que ainda não haviam conseguido. Sendo o autor de muitas extensões populares, me vi no cruzamento de meus clientes que se esforçavam muito para obter essas extensões finais. Poucos sites prontos e PHP 8.0 saindo. Minha ideia de calendário do advento teve que ser descartada. Os esquemas mais bem elaborados de ratos e homens, como se diz na Escócia.
Logo depois do Natal, fiz meu próprio sprint, finalizando o conteúdo desta série e compactando-o em cinco longos artigos que poderia publicar como minha contagem regressiva de cinco dias para o Ano Novo. Consegui tocar na superfície de quase tudo o que realmente importa, desde por que se preocupar em otimizar seu site, até dicas sobre como construir seu site, otimizar seu conteúdo estático, fazer uma verdadeira ginástica e, por fim, fazer com que seu conteúdo valha a pena ser lido.
Espero que você tenha gostado desta série tanto quanto eu gostei de escrevê-la. Espero que pelo menos tenha lhe dado uma pequena vontade de começar a otimizar seus sites e possivelmente ajudado você a aprender algo novo ou a redescobrir algo esquecido. Tenha um Feliz Ano Novo e que este ano seja livre de pandemias e desastres!
Nota do tradutor
Muito agradecido ao autor (grande Nicholas K. Dionysopoulos) pela generosa divulgação da série de artigos e também por autorizar a publicação desta tradução.
Ribamar FS
25 de outubro de 2023.
- Detalhes
- Ribamar FS By
- Categoria: Desempenho
- Hits: 98
Performan em sites Joomla
Por
Nicholas K. Dionysopoulos
Em 5 partes:
Origiais em inglês
https://www.dionysopoulos.me/joomla-performance-tuning-i-start-at-the-beginning.html
https://www.dionysopoulos.me/joomla-performance-tuning-ii-basic-settings.html
https://www.dionysopoulos.me/joomla-performance-tuning-iii-static-media-optimization.html
https://www.dionysopoulos.me/joomla-performance-tuning-iv-site-building-calisthenics.html
https://www.dionysopoulos.me/joomla-performance-tuning-v-content-quality.html
Quarta parte
Joomla Performance Tuning IV: Site building calisthenics
Na terceira parte desta série, descrevi como extrair mais desempenho do seu site otimizando os arquivos de mídia estáticos. Hoje falarei sobre como dar os retoques finais que deixam seu site mais sofisticado e profissional. Eles têm a ver principalmente com a forma como o seu site interage com os mecanismos de pesquisa e as redes sociais, mas também há um pouco de desempenho aí. Acho que informações sobre como aprimorar seu site são a melhor forma de se despedir deste ano.
Calistenia de construção de sites
Dar beleza, força e vigor ao sites
Se você implementou todas as recomendações até agora, você está a cerca de 90% do caminho para um site com bom desempenho, boa classificação e fácil de manter. Esta seção é sobre como obter esse desempenho extra sem exagerar.
O que são "comprimentos bobos", ouço você perguntar com cansaço, tendo visto que algumas das recomendações aqui não são exatamente o que chamaríamos de diretas. Bem, existem pessoas que estão acostumadas a trabalhar em sites massivos, pelo menos em termos de volume de visualizações de páginas atendidas, que recomendarão ações que façam sentido no contexto dos sites que constroem, mas não no contexto dos sites de médio a pequeno porte. sites (realisticamente, extremamente pequenos) que a maioria das pessoas que lêem este artigo tendem a construir. Aqui estão algumas das recomendações que vi e que fazem sentido apenas em alguns contextos, mas são apresentadas como um axiomático Caminho Único e Verdadeiro:
Remova todos os espaços em branco usando substituições de modelo que usam concatenações de strings PHP para todo HTML. A maioria de vocês acha que isso é uma piada. Faz sentido quando você atende centenas de milhares de visualizações de páginas todos os dias em uma nuvem pública que cobra pelo volume de dados servidos. Transformar uma página de 300 KB em uma página de 299 KB tem um impacto financeiro apreciável quando se trata de trezentas mil visualizações de página por dia. Não faz sentido quando seu site tem de algumas centenas a milhares de visualizações de página por dia. Mais ainda, considerando o que você perde: você não tem destaque de sintaxe, é notoriamente difícil entender o que diabos está acontecendo e boa sorte para encontrar aquele DIV de fechamento ausente que estraga seu modelo.
Usando estruturas CSS "mínimas" e substituindo a saída de cada extensão instalada em seu site. Isso faz sentido em sites grandes com um orçamento grande, pois não apenas reduz a quantidade total de CSS que você veicula, mas também garante consistência absoluta de tudo o que é exibido no site. Também é notoriamente difícil de implementar porque você está tentando substituir TUDO primário e de terceiros e, em muitos casos, você precisa "hackear o núcleo" (modificar os arquivos PHP de algumas extensões) para alterar ou remover classes CSS codificadas ou hard HTML codificado. A implementação é uma montanha para escalar e leva uma eternidade. As atualizações são um pesadelo. Você só faz isso se for absolutamente necessário. Além dos maiores sites, que de qualquer maneira não usariam o Joomla, não conheço mais ninguém para quem faria sentido fazer isso em termos comerciais.
Substitua todas as extensões do site para não carregar nenhum arquivo CSS e JS, usando apenas arquivos combinados, minificados e pré-compactados que você implantou com o site. Sim, bem, como acima. É uma tarefa titânica que você nem sequer considera, a menos que haja uma razão absolutamente boa para isso.
Aplicativos da web progressivos (PWA). O principal benefício de um PWA é que seu conteúdo está disponível off-line. A desvantagem é que fica substancialmente mais complicado construir um site como esse, especialmente quando você se aventura fora do conteúdo principal. Para alguns sites, faz sentido. Por exemplo, se você estiver construindo um recurso educacional, implementá-lo como um PWA pode estar fazendo a obra de Deus, já que você permite que um aluno fique à espreita fora de um estabelecimento com uma rede WiFi aberta, basicamente baixe o material no qual ele está interessado e volte para casa para estudar sem degradar sua experiência. Para a maioria dos sites, entretanto, isso não faz sentido ou é uma coisa realmente idiota de se fazer. Por exemplo, não quero que o site da sua marca fique para sempre no cache do meu navegador, especialmente se eu tiver um dispositivo de baixo custo com armazenamento limitado que poderia usar de maneira muito melhor. Então, você sabe, se você decidir seguir o caminho do PWA, certifique-se de que realmente há necessidade disso, em vez de "é a nova moda e todas as crianças legais estão fazendo isso".
Em vez de sugestões elaboradas e muitas vezes irrealistas como essa, vou me concentrar nas coisas mais simples que você provavelmente usará nos sites Joomla que criar.
PS: Por favor, não escreva comentários raivosos sobre como todas essas técnicas fazem sentido em todos os sites porque, você sabe, elas não fazem. Você pode ter o privilégio de trabalhar para poucos, selecionar todos os anos clientes que paguem bem e tenham tempo para você implementar essas técnicas elaboradas, entregar o site e não olhar para trás. Esse é o seu privilégio, não a realidade que a maioria das pessoas enfrenta. A maioria das pessoas trabalha com prazos apertados, orçamentos ainda mais apertados, mudanças diárias de metas e faz o trabalho pesado de manter os sites dia após dia.
Cartões OpenGraph e Twitter
Se você já digitou uma URL em uma rede social como o Facebook (e suas outras propriedades da web, como Instagram, Messenger e WhatsApp) ou Twitter, você deve ter visto algo interessante acontecendo. Você recebe uma espécie de cartão com uma imagem e uma breve descrição do conteúdo da página. Você pode até obter links para o autor ou editor do conteúdo dessa rede social. Como funciona essa mágica? A resposta, meu amigo, NÃO está soprando no vento, são meta tags. Ou seja, as metatags OpenGraph e Twitter Card.
Existem duas maneiras de fazer isso: usar uma extensão de terceiros; ou editar seu template e fazer substituições de template.
A primeira maneira é sem dúvida muito mais simples. Primeiro, você precisará usar o plug-in do site Phoca para adicionar o namespace OpenGraph necessário ao seu elemento HTML. Edite as opções do site e defina a opção “Atributos HTML XMLNS” para:
xmlns:og="https://ogp.me/ns#",xmlns:fb="https://www.facebook.com/2008/fbml"
Em seguida, use o plug-in de conteúdo Phoca Open Graph para configurar suas tags OpenGraph e Twitter Card para seu conteúdo. Observe que existem dois plug-ins, um chamado Phoca Open Graph Plugin (é o que você precisa) e Phoca Open Graph System Plugin.
A desvantagem de usar plug-ins é que, bem, há mais código que precisa ser carregado em seu site e você realmente não precisa deles se puder editar seu template. A primeira mudança é obviamente alterar o elemento HTML raiz do seu template para incluir o namespace do OpenGraph, por exemplo:
<html lang="<?php echo $this->idioma; ?>" dir="<?php echo $this->direção; ?>" prefix="og: http://ogp.me/ns#" >
O leitor astuto pode perceber que estamos usando prefixo em vez de um namespace XML. Esta é a forma recomendada que funciona em navegadores mais recentes, ou seja, Internet Explorer 10 e posterior.
Em seguida, você precisa criar substituições de template para exibição de categorias e artigos que incluam as tags OpenGraph e Twitter Card necessárias. Por exemplo, uma substituição de template de artigo (templates/MY_TEMPLATE/html/com_content/article/default.php) pode ser algo como:
$imagesRegistry = new \Joomla\Registry\Registry($this->item->images ?? '{}');
$imageIntro = $imagesRegistry->get('image_intro', null);
$imageFull = $imagesRegistry->get('image_fulltext', $imageIntro);
$canonicalURL = Route::_(ContentHelperRoute::getArticleRoute($this->item->id), true, Route::TLS_IGNORE, true);
$doc->setMetaData('og:type', 'blog');
$doc->setMetaData('og:título', $this->item->título);
$doc->setMetaData('og:descrição', $doc->getDescription());
$doc->setMetaData('og:nome_do_site', $app->get('nomedosite'));
$doc->setMetaData('og:url', $canonicalURL);
$doc->setMetaData('og:imagem', $imageFull);
$doc->setMetaData('twitter:cartão', 'summary_large_image');
$doc->setMetaData('twitter:site', '@seu_twitter_handle');
$doc->setMetaData('twitter:criador', '@seu_twitter_handle');
$doc->setMetaData('twitter:descrição', $doc->getDescription());
$doc->setMetaData('twitter:título', $this->item->título);
Uma substituição de template de blog de categoria também precisaria de um código semelhante ao seguinte:
$canonicalURL = Route::_(ContentHelperRoute::getCategoryRoute($category->id), true, Route::TLS_IGNORE, true);
$doc->setMetaData('og:type', 'blog');
$doc->setMetaData('og:title', $this->params->get('page_title', $category->title));
$doc->setMetaData('og:descrição', $doc->getDescription());
$doc->setMetaData('og:nome_do_site', $app->get('nomedosite'));
$doc->setMetaData('og:url', $canonicalURL);
$doc->setMetaData('og:image', $category->params->get('image'));
$doc->setMetaData('twitter:cartão', 'summary_large_image');
$doc->setMetaData('twitter:site', '@seu_twitter_handle');
$doc->setMetaData('twitter:criador', '@seu_twitter_handle');
Usar substituições de template obviamente funciona melhor se você já pretende criar seu próprio template, criando, portanto, grandes quantidades de substituições de template de qualquer maneira. Se não tiver certeza, escolha o terceiro método de plug-ins.
Pré-busca de DNS e pré-carregamento de recursos externos
Algum tempo atrás na série eu disse que os navegadores não sabem magicamente quais arquivos precisam solicitar quando estão carregando a página, eles começam a carregar os arquivos quando descobrem que precisam deles ou você os envia para o navegador com HTTP/2 Push . Eu menti um pouco. Você pode dar algumas dicas ao navegador para que ele comece a preparar as coisas enquanto ainda está baixando os primeiros bytes do seu conteúdo HTML usando as tags de pré-busca e pré-carregamento de DNS. Mas acho que estou me adiantando.
Pré-busca de DNS
Quando descrevi como um navegador recupera arquivos CSS, JavaScript e de imagem necessários para renderizar a página, usei um modelo simplista onde o navegador envia uma solicitação para "seu servidor". A suposição tácita era que "seu servidor" se refere ao mesmo servidor e nome de domínio daquele de onde está carregando o conteúdo HTML. Na maioria dos sites Joomla, esse é realmente o caso. No entanto, seu site pode estar usando um CDN externo para hospedar alguns arquivos de mídia, incluir CSS do Google Fonts ou um recurso semelhante, carregar JavaScript de um serviço externo e assim por diante. Todos esses são recursos hospedados em um nome de domínio diferente daquele que hospeda seu site e entrega seu conteúdo HTML. Seu navegador não pode se conectar magicamente a esses nomes de domínio externos; os nomes de domínio precisam ser resolvidos primeiro para um endereço IP por meio de uma consulta DNS.
As consultas DNS podem ser lentas, especialmente em conexões de alta latência, como satélite, celular ou apenas WiFi compartilhado de má qualidade. Isso adiciona um atraso no carregamento desse recurso, que pode variar de irritante (grandes mudanças de layout) a totalmente problemático (uma inclusão de JavaScript não adiada e não assíncrona está fazendo com que a página pare de carregar).
Usando a pré-busca de DNS, você pode avisar ao navegador, basicamente informando que ele precisará resolver esses nomes de domínio durante a renderização da página. O navegador pode fazer as consultas DNS enquanto gira os polegares, esperando que um arquivo JavaScript ou CSS de bloqueio seja finalmente carregado, economizando algum tempo do usuário nas partes posteriores da renderização da página.
Outro bom motivo para fornecer a dica de pré-busca de DNS é quando você sabe que uma interação do usuário fará com que um recurso seja carregado de um site externo. Por exemplo, se você sabe que clicar em um botão Curtir causará uma conexão com o nome de domínio de uma rede social, faz sentido informar ao navegador para resolver o nome de domínio com antecedência para fazer com que esse botão pareça mais responsivo à interação do usuário.
Existem duas maneiras de fazer isso: usando uma extensão de terceiros ou editando seu template.
Você pode (ab) usar o plugin HeadTag de Michael Richey para inserir as meta tags necessárias em seu site. Use a guia Tags de grupo de usuários, adicione uma regra para o grupo de usuários públicos, já que este é o grupo de usuários que se aplica tanto a convidados quanto a usuários logados, e selecione o tipo de tag personalizada. A “Declaração de script/estilo ou tag personalizada” a ser inserida é uma ou mais linhas de pré-busca de DNS. Por exemplo:
<link rel="dns-prefetch" href="https://fonts.gstatic.com">
<link rel="dns-prefetch" href="https://fonts.googleapis.com">
<link rel="dns-prefetch" href="https://www.google.com">
<link rel="dns-prefetch" href="https://www.gstatic.com">
Observe que o atributo href é a raiz do domínio. Não há caminho.
Se estiver modificando seu template, você pode usar o código PHP como o seguinte antes de começar a gerar o elemento HEAD no documento HTML:
/** @var \Joomla\CMS\Application\SiteApplication $app */
$app = JFactory::getApplication();
/** @var \Joomla\CMS\Document\HtmlDocument $doc */
$doc = $app->getDocument();
$doc->addCustomTag('<link rel="dns-prefetch" href="https://fonts.gstatic.com"> ');
$doc->addCustomTag('<link rel="dns-prefetch" href="https://fonts.googleapis.com"> ');
$doc->addCustomTag('<link rel="dns-prefetch" href="https://www.google.com"> ');
$doc->addCustomTag('<link rel="dns-prefetch" href="https://www.gstatic.com"> ');
Pré-conectar
Fazer com que o navegador faça a consulta DNS com antecedência é ótimo. Se você, no entanto, sabe que o navegador definitivamente precisará se conectar ao site externo para extrair recursos usados para renderizar a página – como CSS, JavaScript, imagens ou arquivos de fonte – faz ainda mais sentido dizer ao navegador para abrir uma conexão HTTP com o servidor externo e mantenha-o pronto.
Isso funciona exatamente da mesma maneira que a pré-busca de DNS, exceto que em vez de rel="dns-prefetch" você usa rel="preconnect". O caso de uso prático que encontrei para isso é o Google Fonts, onde você definitivamente sabe que o navegador precisará se conectar a fonts.gstatic.com para recuperar o arquivo de fonte real. Também estou planejando usá-lo na página de vídeo do nosso site comercial para iniciar uma conexão com o CDN de onde o vídeo e a imagem do quadro do banner são recuperados, reduzindo apenas um pouquinho o tempo necessário para iniciar a reprodução do vídeo.
Pré-carregamento de recursos
Em alguns casos, os arquivos que precisam ser carregados não são imediatamente óbvios para o navegador, apenas analisando o HTML da sua página. Alguns recursos podem ser referenciados a partir de um arquivo CSS ou JavaScript. Quando isso acontece, o navegador diz "ah, ótimo, deixe-me adicionar outro arquivo à minha lista de tarefas". Isso pode ter um efeito adverso no desempenho do seu site porque esse arquivo pode ser importante, por exemplo. um arquivo de fonte ou imagem que causará uma mudança de layout ou um arquivo JSON ou JavaScript hospedado externamente que só se tornará aparente quando o navegador terminar de analisar e executar outra parte do JavaScript. Este último é muito comum ao incluir código JavaScript de serviços de terceiros.
Novamente, você pode avisar seu navegador, dizendo-lhe que ele precisará recuperar tal ou tal arquivo. Ao dar a dica logo no início da seção HEAD do documento HTML, o navegador pode otimizar a recuperação desse arquivo, ou seja, começar a baixá-lo em segundo plano enquanto seu thread principal está ocupado aguardando e analisando qualquer bloqueio de CSS e JavaScript na página.
Assim como a pré-busca de DNS, o pré-carregamento de recursos funciona colocando elementos LINK especiais no HEAD do site.
Se você estiver usando um plugin para fazer isso, os elementos LINK ficarão assim:
<link rel="preload" href="https://www.example.com/media/jui/fonts/IcoMoon.woff" as="font" crossorigin="anonymous">
Da mesma forma, ao editar o arquivo index.php do seu template, ele ficará assim:
$doc->addCustomTag(sprintf('<link rel="preload" href="/%smedia/jui/fonts/IcoMoon.woff" as="font" crossorigin="anonymous">',Joomla\CMS\Uri\Uri::root(true )));
É importante observar que, diferentemente da pré-busca de DNS, você fornece uma URL completa para um arquivo no atributo href. Além disso, o atributo as é obrigatório e informa ao navegador a intenção de uso desse arquivo, por exemplo. fonte, imagem, vídeo etc. O atributo crossorigin é essencialmente obrigatório para navegadores modernos e os instrui como lidar com a autenticação de solicitação. Configurá-lo como anônimo não envia cookies, autenticação HTTP ou certificados SSL do lado do cliente e é sempre permitido. Configurá-lo para use-credentials passará cookies, autenticação HTTP ou certificados SSL do lado do cliente, mas está sujeito à política de recursos de origem cruzada do site, que pode efetivamente impedir a solicitação, anulando seu esforço em sugerir o navegador.
Trocar fontes
Este é um recurso importante quando você usa fontes personalizadas. Por padrão, o navegador tentará adivinhar se deve exibir algum texto enquanto sua fonte personalizada ainda não foi carregada e analisada. Se a sua fonte CSS não incluir uma fonte de sistema substituta, o comportamento padrão é "bloquear", o que significa que seu navegador não exibirá nenhum texto antes de recuperar a fonte personalizada que você especificou. Você já visitou um site que exibia todo o texto para sempre e ficou frustrado ao olhar para uma página quase toda em branco com alguns elementos de imagem aqui e ali até puf! todo o texto estava lá de repente? Sim, é por isso.
Felizmente, você pode dizer ao navegador para fazer algo diferente usando o atributo CSS font-display. Configurá-lo para swap significa que o navegador ficará impaciente e voltará à fonte padrão enquanto aguarda o download da fonte personalizada. Quando a fonte personalizada for baixada, mesmo que demore vários minutos, a página será renderizada novamente com a nova fonte. Se você configurá-lo como substituto, o navegador também ficará impaciente, mas se a fonte personalizada não carregar em segundos, ele permanecerá com a fonte do sistema substituto e ignorará completamente a fonte personalizada.
Se você estiver usando o Google Fonts, basta substituir /css? com /css2? no URL e anexando &display=swap. Por exemplo, carregar o Noto Sans torna-se:
<link href="https://fonts.googleapis.com/css2?family=Open+Sans&display=swap" rel="stylesheet">
A melhor coisa a fazer é configurar boas fontes substitutas e definir a exibição da fonte para troca. Para fontes de ícones, você deve usar block para que o que seja renderizado seja um espaço em branco enquanto a fonte do ícone está carregando.
Falando em alternativas de fontes, você deve incluir fontes do sistema como alternativas. Por exemplo, fontes sem serifa podem ter um substituto de
BlinkMacSystemFont, -apple-system, "Segoe UI", "Roboto", Helvetica, Arial, sans-serif
que abrange dispositivos Apple mais novos e mais antigos, Windows 7 a 10, Android e sistemas legados, preferindo a interface de usuário padrão sem fonte serifada em cada plataforma. A ideia é que o usuário veja uma fonte familiar em vez do substituto sem serifa padrão, normalmente mais feio. Em dispositivos Apple, por exemplo, o padrão é a fonte do sistema San Francisco em vez da fonte Helvetica.
Ícones do site (favicons)
Nos velhos tempos, quando os dinossauros vagavam pela Terra e 800x600 pixels eram considerados “alta resolução” – isso seria por volta de 2001 – havia favicons de 16x16 pixels, originalmente destinados a apresentar um logotipo de site nos sites favoritos marcados pelo usuário. Avançando duas décadas, esses ícones não têm mais 16 pixels quadrados ou estão limitados a marcadores.
É claro que os favicons ainda são usados para marcadores e guias de sites, assim como faziam há 20 anos. Eles também são usados para exibir ícones de toque em smartphones e tablets quando você cria um atalho para o site na tela inicial. Além disso, eles são usados por serviços de terceiros para criar um logotipo para o seu site. Se você não sabia sobre esse uso, confira este CodePen de terceiros(https://codepen.io/Jivings/pen/eYdpBOQ).
Para complicar ainda mais as coisas, existem vários tamanhos exigidos por diferentes gerações de smartphones, tablets, navegadores e sistemas operacionais. Você pode encontrar uma ótima referência para tudo isso em https://github.com/audreyfeldroy/favicon-cheat-sheet
Se criássemos uma lista que suportasse todos os dispositivos, navegadores e sistemas operacionais de 2013 a 2020, inclusive, teríamos o seguinte:
Um arquivo ICO contendo 16x16, 24x24, 32x32, 48x48 e 64x64 pixels.
Sete arquivos PNG nos tamanhos 32x32, 128x128, 152x152, 167x167, 180x180, 192x192 e 196x196 pixels.
Um PNG de 144x144 pixels e uma cor de fundo para os blocos do site da UI Moderna do Windows que estão obsoletos, mas ainda não foram removidos (e muito usados no Windows 7, que as pessoas ainda usam por qualquer motivo).
Adicioná-los ao Joomla requer editar o arquivo index.php do template e colocá-lo antes de gerar o HEAD do documento HTML. Supondo que seus arquivos estejam armazenados em images/logos/favicon temos o seguinte código:
$doc = JFactory::getApplication()->getDocument();
$baseUrl = JUri::base();
// O bom e velho 16px
favicon quare
$doc->addFavicon($baseUrl . 'images/logos/favicon/favicon-16.ico');
// Fallback padrão: 152x152 pixels
$doc->addHeadLink($baseUrl . 'images/logos/favicon/favicon-152.png', 'apple-touch-icon-precomposed', 'rel');
// Bloco da UI moderna do Windows
$doc->setMetaData('msapplication-TileColor', '#d43431');
$doc->setMetaData('msapplication-TileImage', $baseUrl . 'images/logos/favicon/favicon-144.png');
//Todos os outros tamanhos
$doc->addHeadLink($baseUrl . 'images/logos/favicon/favicon-196.png', 'apple-touch-icon-precomposed', 'rel', ['tamanhos' => "196x196"]);
$doc->addHeadLink($baseUrl . 'images/logos/favicon/favicon-192.png', 'apple-touch-icon-precomposed', 'rel', ['tamanhos' => "192x192"]);
$doc->addHeadLink($baseUrl . 'images/logos/favicon/favicon-180.png', 'apple-touch-icon-precomposed', 'rel', ['tamanhos' => "180x180"]);
$doc->addHeadLink($baseUrl . 'images/logos/favicon/favicon-167.png', 'apple-touch-icon-precomposed', 'rel', ['tamanhos' => "167x167"]);
$doc->addHeadLink($baseUrl . 'images/logos/favicon/favicon-152.png', 'apple-touch-icon-precomposed', 'rel', ['tamanhos' => "152x152"]);
$doc->addHeadLink($baseUrl . 'images/logos/favicon/favicon-128.png', 'apple-touch-icon-precomposed', 'rel', ['tamanhos' => "128x128"]);
$doc->addHeadLink($baseUrl . 'images/logos/favicon/favicon-32.png', 'icon', 'rel', ['tamanhos' => "32x32"]);
O problema óbvio é que você precisa se lembrar de fazer todas essas alterações que podem ser impraticáveis. Você pode automatizar isso enviando apenas dois arquivos em sua pasta images/logos/favicon:
favicon.ico que você ainda precisa gerar, mas pode escapar incluindo apenas o ícone legado de 16x16px
favicon.png um PNG transparente de 512x512 pixels com a versão de alta qualidade do seu logotipo
Você pode então usar este código substancialmente mais complicado para gerar automaticamente todos os tamanhos necessários:
/**
* Generate favicons.
*
* You need to upload two files to the $basePath folder, by default images/logos/favicon :
* - favicon.ico which includes 16x16, 24x24, 32x32, 48x48 and 64x64 pixel images.
* - favicon.png a 512x512 pixel transparent PNG
*
* @param string $basePath Path with your favicons relative to your site's root
* @param int[] $favIconSizes List of sizes to generate e.g. [32, 57, 152], see https://github.com/audreyr/favicon-cheat-sheet
* @param string|null $tileColor HTML hex color for the IE Modern UI tile icon, null to skip generating it
* @param int $defaultSize Fallback favicon size when the browser doesn't request a specific dimension
*/
$faviconGenerator = function (string $basePath, array $favIconSizes, ?string $tileColor, int $defaultSize = 152) use ($doc) {
$ensureSize = function (int $size) use ($basePath) {
$filePath = JPATH_SITE . '/' . $basePath . '/favicon-' . $size . '.png';
if (!file_exists($filePath))
{
try
{
(new \Joomla\CMS\Image\Image(dirname($filePath) . '/favicon.jpg'))
->resize($size, $size)
->toFile($filePath, IMAGETYPE_PNG, ['quality' => 9]);
}
catch (\Exception $e)
{
}
}
return basename($filePath);
};
$baseUrl = Uri::base(false) . $basePath . '/';
// Fallback .ICO file
$doc->addFavicon($baseUrl . 'favicon.ico?' . $doc->getMediaVersion());
// Default favicon
$doc->addHeadLink($baseUrl . $ensureSize($defaultSize) . '?' . $doc->getMediaVersion(), 'apple-touch-icon-precomposed', 'rel');
// Internet Explorer Modern UI (formerly Metro) tile icon, classic Edge
if (!is_null($tileColor))
{
$doc->setMetaData('msapplication-TileColor', $tileColor);
$doc->setMetaData('msapplication-TileImage', $baseUrl . $ensureSize(144) . '?' . $doc->getMediaVersion());
}
// All other favicons
foreach ($favIconSizes as $size)
{
$doc->addHeadLink($baseUrl . $ensureSize($size) . '?' . $doc->getMediaVersion(), 'apple-touch-icon-precomposed', 'rel', ['sizes' => "{$size}x{$size}"]);
}
};
$faviconGenerator('images/logos/favicon', [
// Favicons size reference: https://github.com/audreyr/favicon-cheat-sheet
32, // Default fallback for most desktop browsers.
// 57, // Deprecated: Standard iOS home screen (iPod Touch, iPhone first generation to 3G), old Android
// 72, // Deprecated: First- and second-generation iPad
// 76, // Deprecated: iPad home screen icon
// 96, // Deprecated: GoogleTV icon
// 114, // Deprecated: iPhone retina touch icon with iOS <= 6
// 120, // Deprecated: iPhone retina touch icon with iOS >= 7
128, // Chrome Web Store icon & Small Windows 8 Star Screen Icon
// 144, // Deprecated: IE10 Metro tile for pinned site, iPad Retina with iOS <=> 6
152, // iPad Retina with iOS >= 7
167, // iPad Retina with iOS >= 10 (in practice iOS will still use 152×152)
180, // iPhone Retina
192, // Google Developer Web App Manifest Recommendation
// 195, // Deprecated: Opera Speed Dial icon (Not working in Opera 15 and later)
196, // Chrome for Android home screen icon
// 228, // Deprecated: Opera Coast icon
], '#d43431');
Este código pode não produzir os melhores resultados em todas as circunstâncias. Os logotipos reduzidos podem parecer um pouco desfocados. Sempre que possível, gere você mesmo os PNGs a partir de uma fonte vetorial e ajuste manualmente o tamanho dos arquivos PNG com pngcrush ou uma ferramenta semelhante.
Avisos de análises e cookies
Como você está navegando na web como todos nós, você já deve estar profundamente frustrado com os banners de cookies que ocupam todos os cantos da web. Na maioria dos casos, os únicos cookies aplicáveis que não são obrigatórios são aqueles utilizados por serviços analíticos como o Google Analytics. Se o seu site precisa mostrar um banner de cookie só porque você está usando o Analytics, pare e pense: você realmente precisa dos recursos fornecidos pelo Google Analytics ou serviços semelhantes?
Na maioria dos casos, você não precisa desses recursos avançados. Se tudo que você precisa é de análises básicas sobre quantas pessoas visitaram seu site, se vieram de pesquisa orgânica ou de um link de referência e de qual país elas vêm, você pode não precisar procurar além do painel de controle de hospedagem, que provavelmente já oferece AWstats ou uma solução semelhante. Eles funcionam analisando os logs de acesso do servidor web e não exigem cookies, portanto, não há banners de cookies em seu site.
Outra solução é usar um serviço de análise auto-hospedado, como o Matomo (anteriormente chamado de Piwik). Ele oferece a maioria dos recursos que você obteria com o Google Analytics, mas como é uma solução original compatível com GDPR e CCPA, você nem precisa mostrar um banner de cookie. Ele pode até importar dados do Google Analytics para que você tenha continuidade de seus dados, se isso for importante para seu caso de uso comercial.
Ao eliminar a necessidade de um banner de cookie, você torna seu site mais fácil de navegar e muito menos frustrante para seus usuários. Saber que você pode fazer isso sem sacrificar os dados necessários para tomar decisões de negócios e sem forçar seus usuários a compartilhar seus dados com terceiros que ganham dinheiro com a venda de anúncios personalizados (o Google é principalmente uma rede de anúncios, se você ainda não o fez). notado) é fortalecedor.
Modo escuro/dark
Muito provavelmente o design do seu site vem apenas em um esquema de cores e é provável que seja um tema “claro”, ou seja, um fundo claro com texto escuro. Este tem sido o caso da maioria dos sites nas últimas duas décadas e é consistente com o que a maioria dos sistemas operacionais costumava oferecer apenas como opção.
Para alguns usuários esse esquema de cores é inacessível e usar cores de tela invertidas simplesmente não é uma solução muito boa; todas as cores são invertidas, incluindo ilustrações e imagens, criando uma experiência chocante. Oferecer também um esquema de cores escuras para o seu site o tornará mais acessível. Isso também tornará seu site mais atraente para pessoas que preferem esquemas de cores escuras em vez de cores claras – um bom ponto a considerar se o público-alvo do seu site são geeks e jogadores.
Já escrevi sobre o que é o Modo Escuro, por que e como usá-lo e recentemente fiz uma apresentação sobre o Modo Escuro. Vou simplesmente criar um link para esses recursos, em vez de me repetir no que já é um artigo muito longo.
https://www.dionysopoulos.me/dark-mode-is-the-new-black.html
https://www.joomlashack.com/blog/tutorials/dark-mode/
AMP
Comecei a trabalhar nesta série de artigos em julho de 2020 e pretendia recomendar AMP (Accelerated Mobile Pages) para o seu site. Já não tenho tanta certeza.
Se você ainda não sabia, AMP é praticamente um subconjunto de HTML com algumas peculiaridades que tornam o carregamento mais rápido em dispositivos móveis. É muito mais restritivo do que um site responsivo normal. O apelo do padrão AMP é que o Google priorizará o conteúdo AMP nos carrosséis de resultados de pesquisa quando um usuário fizer uma pesquisa usando o aplicativo do Google em um smartphone.
A desvantagem é que o AMP é muito específico do Google e não tem suporte fora do ecossistema do Google. Além disso, as pessoas que clicarem nos resultados de pesquisa que apontam para as páginas AMP do seu site verão google.com na barra de endereço do navegador, em vez do seu site. Sinto que essas são as principais desvantagens que isolam você do seu público.
O fato de um membro do Comitê Consultivo da AMP ter renunciado recentemente porque sentiu que o Google havia sequestrado todo o projeto AMP para seu próprio ganho e que o Procurador Geral do Texas entrou com uma ação antitruste contra o Google que acabaria com o tratamento preferencial da AMP no carrossel de pesquisa me faz pensar se faz sentido introduzir AMP em seu site. Pela minha experiência, a integração é praticamente simples se você quiser criar seu próprio modelo personalizado para suas páginas AMP.
Por fim, com base nas análises que coletei em meu próprio site, o AMP não traz tanto tráfego quanto deveria. A maior parte do meu tráfego vem de links diretos de outros lugares, pesquisa orgânica que leva ao meu template responsivo regular e mídia social. O AMP era apenas um pontinho no radar das fontes de tráfego.
Então, em vez de dizer como integrar AMP ao seu site, direi que provavelmente não deveria. Se você estiver, no entanto, ele estará
Antes de implementá-lo, existem soluções para Joomla. Usei o wbAMP, mas devo avisar que criar um modelo personalizado é bastante complicado. Estou inclinado a remover o AMP do meu site em uma iteração futura - muito provavelmente quando eu refazer meu site no Joomla 4.0 assim que a versão do Joomla for lançada oficialmente.
Termina em:
https://www.dionysopoulos.me/joomla-performance-tuning-v-content-quality.html
- Detalhes
- Ribamar FS By
- Categoria: Desempenho
- Hits: 91
Performan em sites Joomla
Por
Nicholas K. Dionysopoulos
Em 5 partes:
Origiais em inglês
https://www.dionysopoulos.me/joomla-performance-tuning-i-start-at-the-beginning.html
https://www.dionysopoulos.me/joomla-performance-tuning-ii-basic-settings.html
https://www.dionysopoulos.me/joomla-performance-tuning-iii-static-media-optimization.html
https://www.dionysopoulos.me/joomla-performance-tuning-iv-site-building-calisthenics.html
https://www.dionysopoulos.me/joomla-performance-tuning-v-content-quality.html
Terceira parte
Joomla Performance Tuning III: Static Media Optimization
Na segunda parte desta série, descrevi como desbloquear um nível básico de desempenho do seu site Joomla com algumas mudanças simples. Hoje estamos nos aprofundando em mídia estática: JavaScript, CSS e arquivos de imagem. Essas mudanças são mais complicadas, mas podem transformar um site lento em um site com desempenho decente. Indiscutivelmente, nem todas essas mudanças fazem sentido para todos os sites, mas os benefícios de desempenho obtidos são substanciais.
Grande parte do seu site vem na forma de arquivos de mídia estáticos: CSS, JavaScript, imagens e também possível áudio e vídeo. Tendemos a não pensar muito neles, considerando-os secundários em relação ao nosso conteúdo, mas normalmente constituem a maior parte dos dados transferidos do servidor do nosso site para o dispositivo do usuário quando ele visita uma página. Além disso, analisar grandes arquivos CSS e JavaScript ou decodificar imagens grandes congela o thread principal do navegador, o que, em termos simples, significa que o navegador não pode fazer nenhum trabalho para renderizar a página (ele só pode baixar mais dados em segundo plano). Além disso, quanto mais arquivos CSS, JavaScript e de imagem você tiver, mais tempo levará para que todos sejam carregados, o que significa que o navegador terá que parar de renderizar a página e recalcular tudo do zero sempre que um desses arquivos terminar de carregar. Isso pode fazer com que a página pareça mais lenta ou causar outros artefatos de renderização, como o conteúdo saltando pela tela (isso é chamado de "Mudança de layout" no jargão do navegador).
Otimize suas imagens
Se você tem um site com muito conteúdo como este blog, a maior parte da transferência de conteúdo da sua página são as imagens. Você provavelmente está acostumado a apenas tirar uma imagem, talvez redimensioná-la ou cortá-la um pouco, carregá-la com o Media Manager do Joomla ou com o Media Manager da JCE e encerrar o dia. Bom para você, mas suas imagens provavelmente não estão otimizadas e são maiores (em Kilobytes, não necessariamente em dimensões) do que deveriam.
Talvez você conheça vaga ou profundamente ferramentas como pngcrush e mozjpeg. Se você se sentir confortável com a linha de comando, use-a para otimizar suas imagens.
Ainda mais fácil, existe uma ferramenta gratuita chamada ImageOptim para macOS que pode executar várias dessas ferramentas em suas imagens e escolher o menor arquivo. É muito simples. Arraste e solte sua pasta de imagens na ferramenta. Espere até terminar. Suas imagens são substituídas por suas versões otimizadas. Obviamente, isso deve ser feito primeiro em uma cópia local do seu site. Você pode usar o Akeeba Backup para criar um backup do seu site e restaurá-lo localmente para funcionar no seu site.
Por favor, não me pergunte sobre alternativas para Windows e Linux. Não tive necessidade de nenhum, não procurei, não usei nenhum.
Torne suas imagens adaptáveis
Você já sabe que seu site será exibido em dispositivos com diferentes tamanhos de tela: telefones Android com orçamento abaixo de 5", smartphones convencionais de 6", phablets ou tablets pequenos de 7"+, tablets de 10" a 11", tablets de 13" a 15". "laptops e enormes monitores de desktop de 23"+. Você já levou isso em consideração ao tornar seu site responsivo, o que significa que seu conteúdo é dimensionado e seu design se contorce para os modos de interação mais apropriados para o tamanho de tela em que seu site está sendo renderizado.
Mas e as suas imagens?
Quando seus dispositivos de destino variam de um telefone econômico com largura de 380 px a um desktop com largura de 5120 px, o mesmo arquivo de imagem não é apropriado para todos os tamanhos. Se você otimizar para tela pequena, a imagem ficará borrada e pixelizada na tela grande. Se você otimizar para a tela grande, a maioria dos visitantes baixará um arquivo desnecessariamente grande para exibir uma imagem muito menor. Otimizar para o tamanho de dispositivo mais comum do seu público é o pior dos dois mundos: dispositivos pequenos baixam um arquivo grande e telas grandes mostram uma foto borrada. Se você também começar a levar em consideração dispositivos HiDPI com densidades de pixels 2x, 3x ou 4x a densidade padrão da tela (o padrão é, aliás, 96 pixels por polegada), você terá um grande quebra-cabeça para resolver. Você escolhe um arquivo razoavelmente pequeno, que será exibido mal em muitos dispositivos, ou um arquivo enorme, que é exibido perfeitamente em todos os dispositivos, mas tem cerca de alguns megabytes de tamanho?
Felizmente, você NÃO precisa escolher. Os navegadores há muito suportam imagens adaptativas. Resumindo, usando o elemento PICTURE com as consultas de mídia apropriadas, você pode selecionar o arquivo de imagem correto para a tela em que seu site está sendo renderizado. Se o tamanho da tela mudar, por ex. Se o usuário girou o dispositivo de retrato para paisagem ou redimensionou a janela do navegador na área de trabalho, o navegador descobrirá de maneira inteligente o que fazer. Se tiver uma imagem grande o suficiente, ela será reduzida. Caso contrário, e você tiver sugerido em seu elemento PICTURE que uma imagem maior está disponível, ela carregará a imagem maior. Enquanto a imagem maior está sendo carregada, a menor aparecerá dimensionada, de modo que, da perspectiva do usuário, há um pouco de desfoque nas imagens que desaparece rapidamente.
Outra coisa mágica que você pode fazer com o elemento PICTURE é fazer com que o navegador selecione o formato de arquivo mais apropriado que ele suporta. A maioria das imagens na web são JPG ou PNG. Esses são formatos de imagem legados, que datam da década de 1990 ou até antes. A maioria dos navegadores modernos também oferece suporte a WEBP, um formato de arquivo de imagem muito mais eficiente que resulta em arquivos muito menores e, ao mesmo tempo, oferece suporte à transparência. Da sua perspectiva como construtor de sites, é como PNG com esteróides. Infelizmente, você não pode simplesmente prosseguir e converter tudo para WEBP porque versões mais antigas de navegadores (e todas as versões do Safari, no momento em que este artigo foi escrito) não suportam WEBP.
Agora você pode estar segurando a cabeça em desespero. O que era simplesmente enviar um único arquivo de imagem e colocar uma tag IMG em seu conteúdo agora se tornou um quebra-cabeça que exige que você crie vários tamanhos e tipos de imagens diferentes. Isso é difícil para você, integrador de sites, e totalmente impossível para seus clientes.
Felizmente, existem extensões Joomla de terceiros que podem cuidar disso para você. Eu usei o XT Adaptive Images Pro. Este site não usa esta extensão. Em vez disso, escrevi uma pequena biblioteca e uma substituição de layout especial para converter imagens automaticamente conforme necessário em meu site. No entanto, não sou um integrador de sites típico, sou principalmente um desenvolvedor back-end. Achei mais fácil escrever código PHP personalizado para meu site do que usar uma solução de terceiros. Para todos que não sou eu, recomendo fortemente o uso de uma extensão de terceiros para implementar imagens adaptativas.
Outro ponto a ser destacado sobre as imagens é que as ilustrações (ao contrário das fotografias) normalmente começam sua vida como um arquivo vetorial em algo como Adobe Illustrator ou Affinity Designer. O que normalmente vemos é que eles são convertidos em arquivos PNG transparentes antes de serem usados em um site. Esta é a maneira menos eficiente de fazer isso. Os navegadores há muito suportam arquivos de gráficos vetoriais escaláveis (SVG), pequenos arquivos de texto que descrevem gráficos vetoriais. Eles tendem a ser muito menores do que os formatos de arquivo otimizados para fotografia (JPG, PNG e até WEBP), são muito mais compressíveis por serem texto simples e podem ser dimensionados para qualquer tamanho, de minúsculo a enorme, em qualquer resolução de tela, sem perder a nitidez. O problema é que o Joomla 3, por padrão, não suporta arquivos SVG por razões políticas disfarçadas de questões de segurança(*). Se você quiser usar arquivos SVG muito mais eficientes para suas ilustrações, você pode instalar meu plugin Joomla SVG Support. Também recomendo usar o JCE Pro e sua substituição de campo de mídia para facilitar a seleção de SVG e outros arquivos de mídia em componentes de terceiros. Uma nota final de cautela: não tente usar arquivos SVG em elementos que esperam obter seu tamanho do conteúdo (arquivos SVG não possuem largura e altura fixas intrínsecas para todos os cuidados do navegador) e não tente usar arquivos SVG como imagens de fundo. Existem maneiras de fazer as duas coisas, mas é provável que você sofra desnecessariamente.
* A parte da “preocupação com a segurança” tem a ver com o fato de que os arquivos SVG podem conter JavaScript. A preocupação foi eliminada com a recomendação do Joomla sobre a adição de código .htaccess, que evita que o conteúdo JavaScript em arquivos SVG seja executado quando o arquivo é acessado diretamente ou colocado na página com uma tag EMBED ou OBJECT. Arquivos SVG colocados em uma página com uma tag IMG nunca têm seu JavaScript executado em nenhuma versão de navegador lançada neste lado de 2013 como precaução de segurança empregada pelos próprios navegadores. O Joomla 3 ainda não adicionará suporte para SVGs, mesmo que esteja alterando 5 linhas de código, porque é considerado um "recurso importante" quando na verdade não é e o Joomla 4 aplicou acidentalmente as alterações de código necessárias de qualquer maneira, sem ninguém perceber, quando o componente Media Manager foi reescrito. Ops :) Portanto, as únicas razões pelas quais o Joomla 3 ainda não suporta arquivos SVG prontos para uso são políticas e não orientadas para a segurança.
Combine JavaScript e CSS
Lembra quando mencionei o fato de que ter muitos arquivos JavaScript e CSS é lento? Vamos dissecar isso um pouco. Em 2010, para cada arquivo necessário do servidor, seu navegador precisava abrir uma nova conexão HTTP(S) com o servidor, o que acarreta uma penalidade de tempo que é exacerbada em conexões com longos tempos de ida e volta (ping). como redes celulares lentas e aguarde a entrega do arquivo. Além disso, os navegadores só podiam baixar até 4 arquivos do servidor por vez. Em 2020, os navegadores podem baixar até 8 arquivos em paralelo de um servidor e manter a conexão com o servidor aberta (sem necessidade de restabelecê-la) até terminarem de renderizar a página. Ainda assim, para cada arquivo que você precisa buscar no servidor, o navegador precisa enviar uma solicitação e aguardar uma resposta. Isso significa que o tempo de ida e volta ainda é importante, ou seja, conexões móveis lentas com tempo de ida e volta muito alto ou acesso a um servidor distante sofrem atrasos proporcionais ao número de arquivos JavaScript e CSS sendo baixados.
Além disso, o navegador não sabe magicamente quais arquivos baixar, apesar do HTTP/2 Push enviar magicamente alguns desses arquivos com o conteúdo HTML principal. Ele precisa analisar a página HTML e começar a baixar os arquivos assim que perceber que eles são necessários. Isso significa que os arquivos JS e CSS serão totalmente carregados pelo navegador em diferentes momentos. Enquanto isso, o navegador não pode ficar parado, girando os polegares. Ele começa a descobrir como renderizar a página e a colocar coisas na tela. Quando chega um novo arquivo CSS ou JS, ele interrompe o que está fazendo, analisa o arquivo e começa tudo de novo. Quanto mais arquivos você tiver, mais ele terá que parar e reiniciar o que está fazendo. Isso significa que as páginas do seu site são mais lentas para serem exibidas por completo, elas “piscam” muito pois o conteúdo precisa mudar de posição na tela e consomem mais bateria dos dispositivos móveis porque o navegador precisa despender muito mais esforço para renderizar sua página. Resumindo, a experiência do usuário é uma merda.
Este é um problema fácil de resolver quando você tem controle total de toda a aplicação web que gera seu site: você sabe quais bits de CSS e JS são usados em cada seção do seu site e os combina em um arquivo reduzido e compactado antes de implantar a aplicação. Isso também significa que você tem um grande subdepartamento de TI lidando apenas com o site e gasta milhares a milhões de dólares para mantê-lo. No outro extremo do espectro, temos sites baseados em CMS prontos para uso, como WordPress e Joomla, que são uma integração de uma plataforma com vários softwares de terceiros. No nosso caso, seria o Joomla (as principais bibliotecas do CMS) e todas as suas extensões próprias e de terceiros. Cada extensão possui seus próprios arquivos CSS e JS. As extensões não se conhecem e não há suporte no próprio Joomla para combinar seus arquivos CSS e JS. É mais fácil e barato construir um site dessa forma, mas o desempenho é péssimo, conforme explicado acima.
Você pode usar extensões de terceiros, como meu plugin Combinator, para forçar o Joomla a combinar arquivos CSS e JS individuais em um único arquivo. Estou usando este plugin neste blog. É muito trabalhoso, com muita tentativa e erro, para acertar tudo, mas vale a pena se o seu site for acessado principalmente por dispositivos móveis em conexões de celular, como este blog aqui.
Usando um CDN
É ótimo saber todos os itens acima e até mesmo se preocupar em implementá-los pelo menos uma vez, para que você possa apreciar totalmente o impacto que eles têm no desempenho do site. Há algo a ser dito, no entanto, sobre a viabilidade de manter essas otimizações de sites mais difíceis de empregar em dezenas ou centenas de sites, ou seja, na frota de sites de manutenção ativa de uma agência web típica. Neste ponto, você pode considerar pagar pelo CloudFlare.
CloudFlare é um serviço combinado de CDN, otimização de sites e segurança de sites. Como um CDN, ele possui nós em todo o mundo que entregarão seus arquivos estáticos e páginas em cache com rapidez aos visitantes do seu site. Os recursos de otimização que oferece podem lidar automaticamente com a compactação de seus recursos estáticos e até mesmo combinar JS e CSS (Rocket Loader). Há um pequeno custo associado, então não é algo que eu recomendo para todos os sites. Por exemplo, estou usando CloudFlare em nosso site comercial, mas não neste blog.
Continua:
https://www.dionysopoulos.me/joomla-performance-tuning-iv-site-building-calisthenics.html
- Detalhes
- Ribamar FS By
- Categoria: Desempenho
- Hits: 74
Performance em sites Joomla
Por
Nicholas K. Dionysopoulos
Em 5 partes:
Origiais em inglês
https://www.dionysopoulos.me/joomla-performance-tuning-i-start-at-the-beginning.html
https://www.dionysopoulos.me/joomla-performance-tuning-ii-basic-settings.html
https://www.dionysopoulos.me/joomla-performance-tuning-iii-static-media-optimization.html
https://www.dionysopoulos.me/joomla-performance-tuning-iv-site-building-calisthenics.html
https://www.dionysopoulos.me/joomla-performance-tuning-v-content-quality.html
Segunda parte
Na primeira parte desta série (https://www.dionysopoulos.me/joomla-performance-tuning-i-start-at-the-beginning.html) descrevi por que ajustar o desempenho do seu site é algo que você deve fazer por razões filosóficas e práticas, bem como por onde começar. Essa postagem foi necessariamente um pouco genérica. Na segunda parte desta série, esta, mergulharemos em algumas das coisas básicas que você pode fazer no Joomla para desbloquear uma quantidade razoável de desempenho.
Configurações básicas do sistema
Ao criar um site, muitas vezes ficamos tão envolvidos no design e na funcionalidade que esquecemos que algumas configurações do sistema muito básicas e bastante simples podem ter um impacto enorme no desempenho de nossos sites. Alguns ajustes simples na Configuração Global antes de entregar o site e algumas verificações simples no servidor podem fazer toda a diferença do mundo.
Cache
A maior parte do tempo gasto no servidor de um site tem a ver com a construção da página que será exibida ao visitante. Joomla, ao contrário do WordPress, possui um sistema de cache integrado. Eu sinto que as pessoas não dão crédito suficiente porque estavam acostumadas com a experiência de cache abaixo da média no Joomla 1.0 a 2.5. Isso foi há 10 a 15 anos.
Vá para a configuração global do seu site e defina o cache como "ON - Progressive Caching". A opção de cache progressivo é a melhor forma de cache integrado do Joomla, garantindo que todos os elementos da sua página sejam armazenados em cache. Quando uma solicitação chega, a página é unida a partir do conteúdo em cache sempre que possível. Isso pode até funcionar para mitigar parte do desempenho perdido em um template pré-construído. Definitivamente, isso ajudará a tornar suas páginas públicas sem login mais rápidas - exatamente o que é mais relevante para a classificação do seu site no mecanismo de pesquisa.
Quanto ao back-end de cache, descobri que o cache de arquivos em um host decente é semelhante ou melhor em desempenho do que o memcached ou o Redis. Heresia, eu ouço você dizer. E eu concordo, até certo ponto. Se você tiver um site realmente grande ou extremamente ocupado, faz sentido usar um servidor memcached ou Redis dedicado. Será mais rápido. Provavelmente, se você está lendo isso, você não tem, de fato, esse tipo de site e está pensando em acelerar um site muito mais para pedestres. Até mesmo o site da minha empresa se enquadra na categoria “mais pedestre” e estamos recebendo um número saudável de dezenas de milhares de visitantes únicos mensais. Isso deve lhe dar uma ideia da escala do site que se beneficiaria com o cache que não é de arquivo.
Compressão do HTML
Se houvesse um concurso para a opção mais negligenciada no Joomla, a compressão de páginas Gzip venceria sem dúvida. Se você ainda não fez isso, vá em frente e ative-o.
Esta opção garante que o conteúdo HTML enviado pelo seu site ao navegador seja compactado usando o algoritmo GZip (também chamado de “deflate”). Isso reduz substancialmente o tamanho total dos dados transferidos para o cliente. A quantidade de tempo economizado na transferência de dados tem um impacto significativo no desempenho do seu site.
Compressão do JavaScript e do CSS
Por mais tentado que você esteja, não use o recurso do seu template ou componente para enviar versões GZipadas de arquivos JavaScript e CSS, nem deve ceder à tentação de usar um plug-in de terceiros para GZipar esses arquivos. Todos esses recursos funcionam empregando um script PHP diretamente acessível pela web, o que é ruim tanto para a segurança quanto para o desempenho do seu site. Esses scripts raramente executam qualquer tipo de controle de acesso, geralmente permitindo que um invasor acesse arquivos que não deveria acessar diretamente. Às vezes até mídia não estática. Ai. No que diz respeito ao desempenho, o tempo mínimo economizado na transmissão de um arquivo menor é perdido pelo tempo gasto pelo servidor web para iniciar um novo thread PHP, ler o arquivo, compactá-lo e então começar a transferir os dados compactados para o navegador.
Eu recomendo fortemente fazer isso através do seu próprio servidor web. Se você estiver usando o Apache, poderá adicionar o seguinte ao seu arquivo .htaccess:
<IfModule mod_deflate.c>
AddOutputFilterByType DEFLATE text/plain text/xml text/css application/xml application/xhtml+xml application/rss+xml application/javascript application/x-javascript image/svg+xml
</IfModule>
<IfModule mod_gzip.c>
mod_gzip_on Yes
mod_gzip_dechunk Yes
mod_gzip_keep_workfiles No
mod_gzip_can_negotiate Yes
mod_gzip_add_header_count Yes
mod_gzip_send_vary Yes
mod_gzip_min_http 1000
mod_gzip_minimum_file_size 300
mod_gzip_maximum_file_size 512000
mod_gzip_maximum_inmem_size 60000
mod_gzip_handle_methods GET
mod_gzip_item_include file \.(html?|txt|css|js|php|pl|xml|rb|py|svg|scgz)$
mod_gzip_item_include mime ^text/plain$
mod_gzip_item_include mime ^text/xml$
mod_gzip_item_include mime ^text/css$
mod_gzip_item_include mime ^application/xml$
mod_gzip_item_include mime ^application/xhtml+xml$
mod_gzip_item_include mime ^application/rss+xml$
mod_gzip_item_include mime ^application/javascript$
mod_gzip_item_include mime ^application/x-javascript$
mod_gzip_item_include mime ^image/svg+xml$
mod_gzip_item_exclude rspheader ^Content-Encoding:.*gzip.*
mod_gzip_item_include handler ^cgi-script$
mod_gzip_item_include handler ^server-status$
mod_gzip_item_include handler ^server-info$
mod_gzip_item_include handler ^application/x-httpd-php
mod_gzip_item_exclude mime ^image/.*
</IfModule>
Seu servidor web é muito mais rápido na compactação de arquivos de mídia estáticos e pode manter os arquivos compactados armazenados em cache na memória para uma entrega mais rápida na próxima vez.
Cache de mídia estática
Reduzir o tamanho da mídia estática com compactação é metade da batalha e é importante principalmente para visitantes de primeira viagem. Quando alguém volta ao seu site, faz sentido que o navegador forneça mídia estática do cache do navegador, sem atingir a rede. Se estiver usando Apache, você pode usar o seguinte código em seu arquivo .htaccess:
<IfModule mod_expires.c>
# Enable expiration control
ExpiresActive On
# CSS and JS expiration:
ExpiresByType text/css "now plus 1 year"
ExpiresByType application/javascript "now plus 1 year"
ExpiresByType application/x-javascript "now plus 1 year"
# Image files expiration: 1 month after request
ExpiresByType image/bmp "now plus 1 year"
ExpiresByType image/gif "now plus 1 year"
ExpiresByType image/jpeg "now plus 1 month"
ExpiresByType image/jp2 "now plus 1 month"
ExpiresByType image/pipeg "now plus 1 month"
ExpiresByType image/png "now plus 1 month"
ExpiresByType image/svg+xml "now plus 1 month"
ExpiresByType image/tiff "now plus 1 month"
ExpiresByType image/vnd.microsoft.icon "now plus 1 month"
ExpiresByType image/x-icon "now plus 1 month"
ExpiresByType image/ico "now plus 1 month"
ExpiresByType image/icon "now plus 1 month"
ExpiresByType image/webp "now plus 1 month"
ExpiresByType text/ico "now plus 1 month"
ExpiresByType application/ico "now plus 1 month"
ExpiresByType image/vnd.wap.wbmp "now plus 1 month"
ExpiresByType application/vnd.wap.wbxml "now plus 1 month"
ExpiresByType application/smil "now plus 1 month"
# Font files expiration: 1 week after request
ExpiresByType application/vnd.ms-fontobject "now plus 1 week"
ExpiresByType application/x-font-ttf "now plus 1 week"
ExpiresByType application/x-font-opentype "now plus 1 week"
ExpiresByType application/x-font-woff "now plus 1 week"
ExpiresByType font/woff2 "now plus 1 week"
ExpiresByType image/svg+xml "now plus 1 week"
# Audio files expiration: 1 month after request
ExpiresByType audio/ogg "now plus 1 month"
ExpiresByType application/ogg "now plus 1 month"
ExpiresByType audio/basic "now plus 1 month"
ExpiresByType audio/mid "now plus 1 month"
ExpiresByType audio/midi "now plus 1 month"
ExpiresByType audio/mpeg "now plus 1 month"
ExpiresByType audio/mp3 "now plus 1 month"
ExpiresByType audio/x-aiff "now plus 1 month"
ExpiresByType audio/x-mpegurl "now plus 1 month"
ExpiresByType audio/x-pn-realaudio "now plus 1 month"
ExpiresByType audio/x-wav "now plus 1 month"
# Movie files expiration: 1 month after request
ExpiresByType application/x-shockwave-flash "now plus 1 month"
ExpiresByType x-world/x-vrml "now plus 1 month"
ExpiresByType video/x-msvideo "now plus 1 month"
ExpiresByType video/mpeg "now plus 1 month"
ExpiresByType video/mp4 "now plus 1 month"
ExpiresByType video/quicktime "now plus 1 month"
ExpiresByType video/x-la-asf "now plus 1 month"
ExpiresByType video/x-ms-asf "now plus 1 month"
</IfModule>
HTTPS e HSTS
Há um equívoco comum de que o HTTPS tem algo a ver com a segurança do seu site, é caro, é lento e você realmente não precisa dele, a menos que esteja fazendo comércio eletrônico ou algo assim. Outro equívoco é que isso torna seu site mais lento.
Esses mitos se originaram no final da década de 1990. Há mais de duas décadas, eles são patentemente falsos.
HTTPS é praticamente obrigatório atualmente. Se você não usar HTTPS, seu site aparecerá com um sinal vermelho informando que é inseguro, assustando os visitantes. Será penalizado pelos motores de busca. Você deve usar HTTPS apenas para corrigir esses dois problemas. Você nem precisa quebrar o cofrinho. Os certificados TLS agora são gratuitos graças ao Let's Encrypt. A maioria dos painéis de controle de hospedagem se integra ao Let's Encrypt, o que significa que você pode literalmente ter seu painel de controle de hospedagem em questão e instalar um certificado TLS gratuito e renová-lo automaticamente. Não há manutenção de sua parte. HTTPS também é super rápido, já que qualquer CPU moderna, lançada nos últimos dez anos, possui aceleração de hardware para as operações criptográficas que utiliza.
Enquanto estiver fazendo isso, lembre-se de definir Forçar HTTPS para site inteiro em sua configuração global. Isso garante que seu site Joomla sempre será entregue via HTTPS, tornando os logins mais seguros no processo. Depois de fazer isso e confirmar que o HTTPS funciona bem com o seu site, adicione o seguinte ao seu .htaccess:
<IfModule mod_headers.c>
Header always set Strict-Transport-Security "max-age=31536000" env=HTTPS
</IfModule>
Isso habilita um recurso chamado HSTS (HTTP Strict Transport Security). Resumindo, ele diz ao seu navegador para nunca tentar se conectar à versão HTTP do seu site, independentemente do que o visitante solicitar. Como isso acontece no navegador, um visitante que digitar seu nome de domínio na barra de endereço sem o prefixo https://, ou clicar em um link com o prefixo http://, sempre chegará à versão HTTPS do seu site sem ter que para primeiro visitar a versão HTTP simples e ser redirecionado pelo Joomla. Isto é muito mais rápido, especialmente em conexões de alta latência, como Internet móvel ou via satélite.
Uma otimização adicional que você pode fazer é enviar seu site para a lista de pré-carregamento HSTS. Embora o HSTS só funcione após a primeira vez que alguém visita seu site, ter seu site na lista de pré-carregamento do HSTS significa que o navegador sabe que seu site está usando HSTS antes da primeira vez que o visitante o visita. Portanto, o navegador nunca tentará carregá-lo por HTTP simples. Novamente, isso economiza tempo para conexões de alta latência, fáceis e gratuitas. O que há para não amar nisso?
Envio de servidor HTTP/2
O motivo oculto para usar HTTPS é que ele nos permite usar HTTP/2. Esta é uma versão mais recente do protocolo HTTP que só funciona em HTTPS, usa cabeçalhos binários e oferece suporte a alguns recursos importantes que aumentam o desempenho do site.
Isso é algo que seu host precisa habilitar em seu servidor. Se você não tiver certeza se sim, acesse https://http2.pro/ e teste a versão HTTPS do seu site. Se disser que HTTP/2 não é compatível, entre em contato com seu host e peça para ativá-lo.
Um dos benefícios do HTTP/2 é que ele suporta push de servidor. Basicamente, seu site pode dizer ao navegador "Ei, percebi que você é novo aqui. Aqui estão alguns arquivos CSS, JavaScript e de imagem que você definitivamente precisará para renderizar esta página. De nada". Ao fazer com que o servidor anexe os arquivos necessários à resposta HTML inicial, o navegador não precisa fazer solicitações separadas para eles. Isso economiza tempo para o navegador enviar uma solicitação ao servidor e esperar que o servidor a processe e comece a enviar dados. Isto é extremamente importante em dois casos. Primeiro, quando o navegador está muito distante do servidor, por ex. o visitante está nos EUA, mas o servidor está em Frankfurt. O tempo de ida e volta, neste caso, é determinado pela velocidade da luz, que é uma constante em nosso universo; você não pode fazer isso ir mais rápido! O outro caso é quando temos alta latência, como Internet móvel ou via satélite. Mesmo em conexões com fio regulares, ele pode economizar centenas a milhares de milissegundos.
Embora o Joomla não tenha suporte integrado para HTTP/2 Server Push (ainda?), você sempre pode usar o plugin Server - HTTP/2 Push de Michael Richy. Lembre-se de que o HTTP/2 Push só acontece na primeira vez que um visitante solicita um recurso durante a sessão do usuário. Ao testá-lo em seu site, lembre-se de não apenas limpar o cache do navegador, mas também os cookies enviados pelo seu site para redefinir a sessão.
Contiua em
https://www.dionysopoulos.me/joomla-performance-tuning-iii-static-media-optimization.html
- Detalhes
- Ribamar FS By
- Categoria: Desempenho
- Hits: 119
Performan em sites Joomla
Por
Nicholas K. Dionysopoulos - https://gravatar.com/sledge81
Em 5 partes:
Origiais em inglês
https://www.dionysopoulos.me/joomla-performance-tuning-i-start-at-the-beginning.html
https://www.dionysopoulos.me/joomla-performance-tuning-ii-basic-settings.html
https://www.dionysopoulos.me/joomla-performance-tuning-iii-static-media-optimization.html
https://www.dionysopoulos.me/joomla-performance-tuning-iv-site-building-calisthenics.html
https://www.dionysopoulos.me/joomla-performance-tuning-v-content-quality.html
Primeira parte
Joomla 4 é uma grande melhoria em relação ao Joomla 3. Imediatamente você obtém um CMS com suporte integrado para dados estruturados (o que anteriormente era chamado de “microdados”), até mesmo diversas opções de cache para atender a qualquer uso, desde sites pessoais leves até portais enormes e movimentados.
Por razões que têm a ver com suas iterações muito antigas e passadas, ele ainda tem a má reputação injustificada de um CMS lento e ruim para SEO. Isto não poderia estar mais longe da verdade. Na verdade, o Joomla 4, sem qualquer software de terceiros, supera seus concorrentes, mesmo quando auxiliados por software de terceiros desenvolvido especificamente.
Melhorar ainda mais seu desempenho e como evitar todas as armadilhas na hora de construir o seu site ou o do seu cliente.
Nesta primeira parte da série falaremos sobre por que isso é importante, em geral, e quais são os primeiros passos óbvios que você pode dar para atingir esse objetivo.
Por que você precisa de um site rápido?
Antes de embarcarmos em nossa aventura para otimizar o desempenho do seu site Joomla, precisamos abordar a questão mais básica: por que isso é importante? Afinal, estamos falando de você ter que trabalhar mais antes de ter seu site pronto para publicação. Vale realmente a pena o esforço, mesmo que já atraia uma quantidade razoável de tráfego orgânico e pareça rápido para você?
Acredito firmemente que vale a pena investir tempo, tanto por razões filosóficas como práticas.
A primeira razão filosófica é que um site lento é um desperdício em muitos níveis. Isso desperdiça o tempo de todos. Esperar de 4 a 5 segundos para uma página carregar pode não parecer um grande desperdício, mas ao longo de um ano e centenas de milhares de páginas que cada um de nós está esperando para carregar, estamos coletivamente desperdiçando pessoas-anos inteiras do nosso tempo. Ao mesmo tempo, desperdiçamos eletricidade para gerar o conteúdo mais lentamente do que o necessário, entregar mais dados do que deveríamos e processá-los mais lentamente do que o necessário para exibição com tudo o que implica sobre a pegada ambiental do seu site.
A segunda razão filosófica é que sites lentos são excludentes. Eles são mais difíceis de alcançar por comunidades carentes que dependem de conexões de Internet lentas ou de alta latência. Seja a Internet via satélite, que é a única ligação viável com o mundo exterior numa aldeia africana, ou o WiFi fraco num parque de estacionamento do McDonald's num distrito escolar pobre nos EUA, o site lento pode estar a criar uma barreira intangível, mas muito real, entre o seu conteúdo e as pessoas que poderiam consumi-lo e se beneficiar dele. Só porque a maioria de nós tem o privilégio de viver em centros urbanos de países desenvolvidos com conexões de Internet rápidas e de baixa latência, não significa que devamos agir como guardiões da informação, omitindo-nos de fazer algo relativamente fácil para aumentar o alcance dessa informação. Isto é especialmente importante se você estiver desenvolvendo sites sem fins lucrativos, educacionais, governamentais ou de outros recursos.
Quanto a razões práticas, comecemos com o problema óbvio de que um site lento cria uma experiência frustrante para o visitante. É provável que eles desistam do seu site e visitem o de outra pessoa. Se permanecerem, é provável que fiquem com um estado de espírito negativo depois de terem sido submetidos a uma série de atrasos longos e desnecessários. Isso enfraquece e prejudica o conteúdo do seu site, desencoraja visitas repetidas e reduz sua taxa de conversão.
A segunda e mais importante razão prática é que os motores de busca não classificam mais o seu site apenas com base no conteúdo e na conexão com outros sites. Eles levam em consideração os Core Web Vitals. Essencialmente, um site que está inchado ou lento para carregar será penalizado nas classificações dos mecanismos de pesquisa. É do seu interesse ter um site rápido, mesmo que você não se importe com o impacto social e ambiental do seu site.
Premissas operacionais
A maioria dos artigos que você deve ter lido sobre otimização de sites tende a ser axiomático. Eles afirmam que existe o Único Caminho Verdadeiro e que você será lançado na condenação eterna se não segui-lo. A ironia do fato de existirem tantas visões axiomáticas mutuamente exclusivas quanto o número de pessoas que escrevem artigos aparentemente escapou a estes autores.
Não existe um Único Caminho Verdadeiro. Mesmo implicando que um site pequeno construído por uma única pessoa em seu tempo livre pode ou, pior, deve seguir a mesma metodologia que um site de médio a grande porte sendo construído e mantido por uma equipe dedicada de pelo menos algumas dezenas de pessoas está fora de questão. de contato com a realidade.
Estou escrevendo esta série de artigos com a maioria dos integradores de sites que usam Joomla, construindo sites sozinhos ou como parte de uma pequena equipe, dentro das restrições de tempo e orçamento impostas por seus clientes. A maioria de vocês está construindo sites de pequeno a médio porte para pequenas e médias empresas ou até mesmo pequenas lojas familiares. Você não pode se dar ao luxo de ficar obcecado em alcançar uma “pontuação perfeita”. Essa é uma meta quase inatingível, e não a expectativa pragmática para cada site. Sim, você pode alcançar uma pontuação perfeita, mas se isso significa que você tem um site que é difícil de construir e manter, isso é realmente algo positivo ou você involuntariamente colocou seu nome no prêmio Darwin?
Você deve otimizar apenas o máximo que puder. Você tem prazos a cumprir e, francamente, algumas das otimizações podem simplesmente consumir uma quantidade desproporcional de seu tempo para ganhos marginais. Comece de forma simples e só vá mais fundo dependendo do prazo e orçamento do seu cliente.
Este é o contexto desta série de artigos. Não é axiomático, é prático. Estou apresentando várias maneiras de otimizar sites do mundo real com uma compensação razoável entre ganhos totais de desempenho e capacidade de manutenção. Estas não são abordagens de sala limpa que funcionam muito bem na teoria, mas na prática requerem muito mais recursos do que os que estão realisticamente disponíveis para a maioria dos nossos leitores.
Vamos colocar isso de outra maneira. Sim, você sempre pode criar um aplicativo baseado em microsserviços e CDN, se desejar. Ou use algumas técnicas realmente avançadas que contornam uma infinidade de limitações impostas pela abordagem única de usar um CMS como Joomla (ou WordPress, ou Drupal, ou...) em vez de construir seu próprio aplicativo personalizado. Mas não estou aqui para dizer por que ou como não usar um CMS. Estou aqui para lhe dizer como você pode usar melhor o CMS de que dispõe para obter melhores resultados dos quais antes não sabia como chegar. Todas essas são técnicas que pratiquei em meus sites e funcionaram mutio bem!
O absolutamente “óbvio”
Quando você usa o Joomla desde o Mambo em 2004, seu antecessor, como o seu, existem algumas verdades básicas sobre como você aborda a construção de sites que parecem bastante óbvias. Aqui está a coisa. Nada é realmente “óbvio”; é tudo uma questão de experiência.
No passado, pensei que as pessoas deviam estar loucas por não verem uma série de pontos que eram dolorosamente óbvios para mim. Eventualmente, percebi que tenho uma experiência única por ter estado no backend de inúmeros sites e adquiri um conjunto único de habilidades ao longo de uma longa carreira... Desculpe, filme errado. O que quero dizer é que percebi que o que é óbvio para mim pode ser bastante misterioso para alguém que está começando agora ou está acostumado a fazer as coisas de uma maneira diferente da minha. Verdade seja dita, se eu pudesse me aproximar de mim mesmo há 16 anos, provavelmente me daria um tapa na cara por fazer coisas que aprendi da maneira mais difícil em algum momento posterior, que são absurdas ou me prejudicam no longo prazo.
Discutirei os três erros mais comuns que vi em sites e como corrigi-los facilmente. Ei, alguns deles nem têm a ver com o próprio Joomla!
Hospedagem
O erro mais comum que vejo é as pessoas escolherem hospedagem compartilhada barata e depois reclamarem que seu site Joomla é lento. Sim, o site deles é lento, mas o Joomla não é o motivo. A hospedagem que você escolhe para o seu site é crucial. Não tente economizar centavos aqui!
Você já se perguntou por que um host barato oferece um preço abaixo de US$ 3 por mês, enquanto um host de boa qualidade cobra de cinco a dez vezes mais por hospedagem compartilhada com especificações iguais ou nominalmente inferiores? A diferença é que o host mais barato tenta amontoar mais sites em um único servidor físico e mantém os custos baixos usando CPUs e memória mais lentas, unidades de disco mecânicas mais lentas e conectividade com a Internet mais limitada. Tudo isso conspira para tornar seu site consideravelmente mais lento para começar. Nenhum ajuste pode salvá-lo quando você começa com uma hospedagem ruim.
Pense assim. Você pode fazer um carro tão aerodinâmico quanto um caça a jato. Se o motor em que ele funciona for um motor monocilíndrico e dois tempos de uma motocicleta, ele não vencerá e atingirá recordes de velocidade. Provavelmente será ultrapassado por alguém caminhando em ritmo acelerado. O motor do seu site é o seu ambiente de hospedagem. Ele determina o desempenho máximo que você pode obter com isso.
Tente encontrar um equilíbrio entre o desempenho ideal e o seu orçamento realista. Se não tiver certeza, escolha um provedor de hospedagem compartilhada de médio porte com boa reputação boca a boca e possivelmente reavalie após alguns meses com tráfego do mundo real. Se o seu cliente ditar a hospedagem, certifique-se de ter o The Talk com ele: explique que não importa o que você faça, a escolha da hospedagem limitará o desempenho do site que você constrói.
Templates pré-construídos
Muitas pessoas que constroem sites estão usando um Template pré-construído com uma infinidade de opções, uma estrutura genérica que tenta ser tudo para todos, normalmente combinada com dezenas de componentes, plugins e módulos para construir um site que não é tão complexo se pense nisso.
Eu entendo o apelo, já que já fiz isso no passado. Você se sente capacitado para mexer no layout do seu site e experimentar diferentes opções até encontrar o que funciona. Eu diria que você deveria fazer isso se achar que esse é o seu processo criativo, mas não necessariamente se limite ao Template genérico pré-construído depois de descobrir como deseja que seu site fique. Se você se sentir desconfortável em criar seu próprio Template, claro, um pré-construído é a única maneira para você, mas tenha em mente que isso limitará suas métricas de desempenho.
O problema objetivo é que um Template genérico é construído para flexibilidade, não para velocidade. Na minha experiência, o carregamento da sua página (Tempo até o primeiro byte - TTFB) pode aumentar em uns bons 1 a 3 segundos apenas por causa de toda a bagagem desnecessária que você está arrastando com você usando esse tipo de Template. Um Template personalizado baseado no Cassiopeia do Joomla 4 é rapido, tem um impacto insignificante, na faixa de uma fração de milissegundo.
Mesmo que você vá até a metade e use apenas uma estrutura de template genérica, ainda estará arrastando muito código desnecessário, a menos que realmente saiba o que está fazendo. Sem mencionar que você instalou uma quantidade substancial de código PHP e JavaScript que precisa ser mantido regularmente por motivos de segurança.
Outro problema com templates pré-construídos e estruturas de templates é que eles tendem a carregar todo o seu CSS e JavaScript no cabeçalho da saída HTML, o que tem um impacto adverso em seus Core Web Vitals, especialmente no First Contentful Paint. Um modelo personalizado baseado em Cassiopeia carregará esses arquivos estáticos adiados, tornando a exibição do seu site muito mais rápida.
Se você tiver as habilidades e o tempo, será melhor criar seu próprio template. Isso parece assustador, mas não é se você já é um construtor de sites Joomla experiente e entende as ferramentas básicas, porém poderosas, do Joomla, como substituições de templates. Você pode usar qualquer estrutura CSS que desejar e começar com o template padrão do Joomla 4, Cassiopeia.
Não sou um desenvolvedor front-end de forma alguma. Consegui facilmente pegar o design criado para o meu site e “traduzi-lo” para um template Joomla 4 baseado em Cassiopeia sem muitos problemas. Bootstrap 5, integrado ao Joomla e ao que Cassiopeia está usando, é extremamente versátil. A única coisa que você precisa entender para tornar possível qualquer tipo de apresentação visual — e responsiva! - é CSS Flexbox.
Não exagere
Existe o velho ditado de “só porque você pode, não significa que deve”. No contexto do Joomla, só porque você pode instalar centenas de extensões não significa que deva!
Com mais de 7.000 extensões no diretório de extensões Joomla, é bastante fácil exagerar e instalar tudo o que existe. Um plugin para isso, um módulo para aquilo, um construtor de páginas em vez de uma simples substituição de template e antes que você perceba, você terá mais de 300 extensões de terceiros carregando em cada página do seu site. Como você pode imaginar, isso faria com que qualquer site ficasse lento.
Vamos falar sobre módulos. Minha observação casual é que 90% dos módulos exibidos em 90% dos sites que visitei ou nos quais trabalhei não têm razão de existir. Ninguém se importa com o clima na sua cidade; se o fizessem, estariam perguntando ao Google, Alexa ou Siri em vez de visitar seu site. Ninguém se importa com as três dúzias de botões, links e banners de conteúdo que você tem na barra lateral. As pessoas querem uma navegação intuitiva, não uma lista telefônica. Pior ainda, os sites de mídia social condicionaram os visitantes do seu site a entrar no modo “cegueira da barra lateral e do banner”, ou seja, eles presumem que esse conteúdo é lixo com o qual não precisam se preocupar. Os módulos podem servir a um propósito verdadeiro, mas use-os com moderação. Não tente “preencher o espaço vazio” com módulos inúteis.
O que nos leva aos plug-ins, especialmente plug-ins de conteúdo e plug-ins de sistema que pesquisam e substituem texto em páginas inteiras. Os plug-ins de conteúdo são executados sempre que o conteúdo é exibido em seu site. Eles precisam fazer algum tipo de inicialização e algum tipo de substituição de texto. Essas operações levam tempo. A pesquisa de página inteira e a substituição por plug-ins do sistema, especialmente se usarem expressões regulares, levam ainda mais tempo. É realmente uma pesquisa e substituição em cada saída de página do seu site uma solução melhor para substituições de modelos, substituições de idioma ou passar algum tempo alterando o conteúdo no back-end ou diretamente no banco de dados?
Quando você combina o abuso excessivo de módulos e plug-ins, você pode acabar com um site que precisa fazer centenas de consultas ao banco de dados e gastar alguns segundos preciosos substituindo coisas no conteúdo que demorou uma eternidade para ser gerado. Sim, este site será muito lento. Na verdade não é culpa do Joomla, é apenas o resultado direto da abordagem de implementação que você adotou. Não direi que é necessariamente ruim, mas também não direi que é o melhor caminho a seguir.
Se você tiver um problema que precisa ser resolvido, usar uma extensão deve ser seu último recurso. Comece primeiro com campos personalizados, substituições de template e substituições de idioma. Se você acha que o site parece “vazio”, crie conteúdo de qualidade, não o encha com módulos inúteis com os quais ninguém se importa, mas ainda assim deixam seu site mais lento. A principal diretriz é KISS: Keep It Stupidly Simple. É mais fácil falar do que fazer e geralmente são necessárias algumas iterações para chegar lá. Lembre-se de sempre reavaliar se você precisa de uma extensão e desativá-la ou desinstalá-la quando não a estiver mais usando.
Substituir em vez de adicionar lixo
A maioria das pessoas aborda o desenvolvimento de sites de seus clientes da mesma forma que um usuário de Android ou iPhone aborda o uso de seu dispositivo: se eu precisar fazer algo, preciso instalar algo. Eu chamo isso de Existe um aplicativo para essa síndrome ou “TAFTS”, para abreviar. Parece uma condição terminal, não é?
Pessoas que sofrem dessa síndrome acabam usando um zilhão de extensões que tornam o site lento e se tornam um grande obstáculo na atualização do Joomla ou do PHP alguns meses depois.
O problema é que você não precisa adicionar lixo ao seu site. Joomla é extremamente flexível imediatamente. Quando você quiser fazer algo, pare e pergunte-se: isso pode ser feito apenas com os recursos básicos do Joomla?
Ao contrário da maioria dos CMS existentes, o Joomla permite que você substitua a forma como ele exibe tudo e qualquer coisa usando substituições de idioma, substituições de template/layout e campos personalizados. Usando essas ferramentas simples, você pode criar conteúdo incrivelmente complexo e muito fácil de gerenciar. Afinal, Joomla descende de um CMS chamado Mambo cujo lema era “poder na simplicidade”.
Usando nada além de substituições de layout e campos personalizados, criei uma página de tutoriais em vídeo para meu site comercial, hospedando automaticamente os vídeos (sem incorporações no YouTube / Vimeo). A página de categorias de vídeo que você acessa é uma visualização de blog de categoria Joomla com uma substituição de template simples e uma pitada de CSS personalizado. Ao clicar em uma categoria, você verá uma lista de vídeos. Esta é apenas uma visualização de lista de categorias com uma substituição de template. A duração do vídeo é um campo de texto personalizado. Existem mais dois campos de URL personalizados apontando para o arquivo de vídeo e a imagem do quadro do pôster. Eles são usados para exibir a parte superior da página de vídeo individual (player de vídeo). Essa página é apenas um artigo. O conteúdo do artigo é a transcrição que você vê mais abaixo na página. A transcrição possui atributos data-timecode que são analisados pelo JavaScript da página, carregados na substituição do template, tornando-os links clicáveis para apontar para pontos específicos no tempo no player de vídeo. É legal e é tudo básico do Joomla. Não há necessidade de uma galeria de terceiros ou de um componente dedicado de tutoriais em vídeo.
Vi a humilde página da lista de tags se tornar um lindo painel de seleção de área de conteúdo para uma organização sem fins lucrativos. Já vi artigos principais com campos personalizados definirem o conteúdo de maneira amigável para um aplicativo da Web com toque inicial, sem nenhum código de terceiros, exceto o manipulador de eventos de toque JavaScript. Já vi substituições de templates muito simples que fazem a página de perfil do usuário do Joomla parecer um serviço profissional de alta qualidade, em vez de um monte de campos agrupados.
É verdade que nem tudo é possível apenas com o núcleo - você não pode razoavelmente fazer comércio eletrônico ou agendar compromissos com o núcleo do Joomla, você precisa de uma extensão ou serviço de terceiros - mas as extensões definitivamente não são a primeira ou única escolha que você tem como um integrador de sites.
Ao aderir a um uso bem planejado e mínimo de extensões de terceiros, você evita tornar o site mais lento e garante sua manutenção a longo prazo. Isto é especialmente importante quando extensões menos usadas desaparecem da face da Terra e você fica com a difícil escolha de reimplementar parcialmente um site ou mantê-lo com uma versão desatualizada do Joomla. Lembrem-se, pessoal, um grama de premeditação vale um quilo de tentativa frenética de consertar uma decisão errada quando já é tarde demais.
Continua em:
https://www.dionysopoulos.me/joomla-performance-tuning-ii-basic-settings.html