Se, depois de ler os artigos acima, continuar a existir uma discrepância entre cliques e sessões difícil de explicar, a latência pode ser responsável por isso. Normalmente, os problemas relativos a cliques e sessões nos quais a latência é um fator têm os seguintes atributos:
- A discrepância entre cliques e sessões não pode ser restringida a uma campanha, grupo de anúncios ou palavra-chave específicos.
- Em todas as campanhas do Google Ads ativas, observa que a contagem de sessões é subestimada de forma consistente em relação aos cliques.
- A segmentação por dispositivo, como, por exemplo, computador, tablet, telemóvel, evidencia uma discrepância que persiste em várias plataformas.
Neste artigo:
- Por que é importante ser rápido
- A posição é importante
- Consequências da falta de velocidade
- Uma solução a curto prazo para cliques curtos
- Como é que sei se o processo é lento?
- Como posso tornar o processo mais rápido?
- Remover redirecionamentos ou atualizar URLs de destino
- CSS sprites
- Utilizar uma RFC (rede de fornecimento de conteúdo)
- Comprimir ficheiros HTML, CSS e JS
- Pedidos de cache populares
- Ponderar o uso de Ajax e de plug-ins, como o Infinite Scroll ou o Lazy Load, para Jquery
- Compressão Gzip
- Atualizar para o Universal Analytics
- Servidores de alojamento da Web mais rápidos
- Mais conselhos e sugestões
Por que é importante ser rápido
Como regra geral, os utilizadores da Internet não são muito pacientes. Isto é demonstrado por estudos como o estudo KissMetrics do qual resultaram algumas afirmações para reflexão, como "Um atraso de um segundo na resposta de uma página pode resultar numa redução de 7% das conversões." e "47% dos consumidores esperam que uma página Web seja carregada num período de dois segundos ou inferior.".
O que significa isto para si? Se o seu Website for muito lento a carregar, existe a possibilidade de os utilizadores desistirem e se voltarem para a sua concorrência, principalmente se a concorrência conseguir publicar o mesmo conteúdo mais rapidamente.
A posição é importante
Perguntam-nos muitas vezes onde é que deve ser colocado o código de acompanhamento do Analytics no código fonte HTML de uma página. A resposta é: depende do rigor com que pretende medir os utilizadores que efetuam rejeições. Se ocorrer um clique e forem necessários vários segundos para uma sessão ser gravada, há uma forte probabilidade de algumas dessas sessões não serem controladas. Em geral, recomendamos que o código de acompanhamento seja colocado imediatamente antes da etiqueta de fecho </head>.
Consequências da falta de velocidade
Cliques curtos: um clique curto ocorre quando um utilizador clica num anúncio e depois, antes de o pedido do código de acompanhamento do Analytics ser acionado, o utilizador clica no botão Retroceder ou fecha o navegador. O Google Ads regista o clique, mas não é registada uma sessão correspondente no Analytics.
De um modo geral, quanto mais lento for o Website a responder e quanto maior for o número de pedidos que surgem antes do fragmento do Analytics, maior é a probabilidade de vir a ter problemas com cliques curtos e dados de sessão em falta.
Uma outra forma de pensar nos cliques curtos é que estes são, na verdade, utilizadores que efetuam rejeições do Website. Ou seja, se não estiver a controlar estas sessões de rejeição, a sua taxa de rejeição poderá ser falsamente baixa.
Dispositivos móveis e cliques curtos: geralmente, os dispositivos móveis funcionam numa infraestrutura de rede mais lenta (redes 3G) do que a maioria das ligações dos computadores (ADSL/cabo). Se segmentar os dispositivos móveis, a necessidade de um Website de resposta rápida é ainda maior para evitar cliques curtos.
Uma solução a curto prazo para cliques curtos
Uma solução a curto prazo consiste em tentar colocar o fragmento de controlo do Analytics o mais acima possível no código fonte HTML, idealmente acima de todos os outros ficheiros Javascript.
Na captura de ecrã acima, pode observar que existem vários pedidos de ficheiro JavaScript que têm de ocorrer (etiquetas assíncronas) antes de o fragmento de controlo do Analytics ser executado. Abordaremos as técnicas de otimização posteriormente, mas, por agora, uma solução a curto prazo será deslocar o fragmento de controlo do Analytics para cima dos outros ficheiros Javascript. Mas não se preocupe: o Analytics não desacelera os tempos de apresentação das páginas, porque se trata de uma etiqueta JavaScript assíncrona. Isto significa que não impedirá que a sua página seja apresentada, mesmo que haja um atraso do servidor do Analytics.
O motivo pelo qual esta é uma solução temporária é que pode ajudá-lo a registar sessões que de outra forma não seriam registadas pelo facto de os utilizadores abandonarem a página mais cedo (uma vez que o fragmento do Analytics não é executado mais cedo). A longo prazo, contudo, pretende reter os utilizadores que efetuam rejeições e resolver o problema inerente, que é um Website de resposta lenta.
Como é que sei se o processo é lento?
Conforme acima referido, colocar o código de acompanhamento do Analytics mais acima no código fonte HTML ajuda até um certo ponto, mas um Website de resposta mais rápida é também importante.
Mas então como saber se o seu Website é lento?
Teste 1
Com uma cache vazia (limpe a cache e os cookies se desejar), abra um novo separador, introduza o seu URL de destino na barra de endereços do navegador e abra as ferramentas do programador do Chrome para o separador de rede.
Carregue o Website e veja a lista de pedidos. Deverá ter um aspeto semelhante a este:
Procure _utm.gif (Analytics clássico) ou recolha (Universal Analytics) e observe a secção da linha cronológica do lado direito. Na ilustração acima, pode verificar que decorreram cerca de 8 segundos desde o momento em que o primeiro pedido foi efetuado (onde estaria registado um clique) até ao pedido do Analytics (onde estaria registada uma sessão).
Se um utilizador clicar no botão Retroceder durante esses 8 segundos, o Analytics poderá não registar uma sessão neste Website, mas o Google Ads terá registado o clique.
Lembre-se da citação do KissMetrics: "Metade dos utilizadores esperam que uma página seja carregada dentro de dois segundos ou menos.". Este Website pode melhorar!
Teste 2
O Analytics capta automaticamente os dados relativos ao tempo de carregamento da página como fazendo parte dos relatórios Velocidade do site.
Este relatório permite-lhe concentrar-se em URLs de destino do Google Ads específicos para avaliar o respetivo desempenho em termos de latência. Neste exemplo em particular, podemos ver que a velocidade do site é de cerca de 25 segundos para este URL específico, o que é efetivamente lento.
Repare como a taxa de rejeição para esta página também é elevada. Embora este URL de destino já origine cliques curtos (ou seja, rejeições), os que são registados têm também uma taxa de rejeição elevada, o que não é um bom sinal.
A velocidade de carregamento de página ideal deveria ser entre 3 e 4 segundos.
Apesar de os relatórios Velocidade do site serem uma boa indicação dos tempos de carregamento de página, por predefinição a amostra baseia-se em apenas 1% do tráfego. Se tiver um número relativamente pequeno de utilizadores diários no seu site, como 100 000 ou inferior, poderá pretender ajustar a amostragem para uma taxa superior, por exemplo, 5%. Desta forma, obterá um maior nível de detalhe para o tempo de carregamento de página e outras métricas de Velocidade do site.
Tenha em atenção que isto cria um pedido adicional e que, em quase todos os casos, não deverá ter um impacto negativo na experiência do utilizador.
Como posso tornar o processo mais rápido?
Os relatórios Velocidade do site do Analytics fornecem agora sugestões de Velocidade do site. Introduza os seus URLs de destino com mais cliques para ver sugestões sobre como tornar essas páginas mais rápidas.
Remover redirecionamentos ou atualizar URLs de destino
Mesmo que os seus redirecionamentos preservem o parâmetro de etiquetagem automática do Google Ads e que o enviem para o URL de destino final, os redirecionamentos acrescentam uma latência adicional entre o clique e o tempo durante o qual a sessão pode ser registada pelo Analytics.
Em alguns casos, os proprietários de sites têm vários redirecionamentos entre o clique do Google Ads e o URL de destino final.
Deve atualizar o seu URL de destino do Google Ads de modo a refletir o URL de destino final para que não seja necessário ocorrerem redirecionamentos.
Em alguns casos, os clientes utilizam um serviço intermediário, como um servidor de cliques para registar o clique do Google Ads, o que é utilizado com frequência pelas plataformas de relatórios de terceiros.
Embora entendamos que pretende gerar relatórios em várias plataformas, este serviço pode funcionar como um obstáculo e tornar a experiência do utilizador mais lenta. Se estiver a ter dificuldades com cliques e sessões registados no Analytics, recomendamos que remova este serviço controlador de cliques por um período limitado para verificar se a proporção de cliques relativamente às sessões melhora. Em seguida, reavalie se pretende continuar o acompanhamento na plataforma de terceiros ou optar por procurar um fornecedor mais rápido.
CSS sprites
Os CSS sprites podem substituir vários pedidos de imagem.
Repare como o Website na ilustração acima tem vários pedidos de imagem (ficheiros .png) para ícones e ficheiros de imagem pequenos. A vantagem dos CSS sprites é simples: em vez de ter vários pedidos de imagem, coloque todas essas imagens num único pedido (uma imagem maior) e utilize o CSS para controlar as partes da imagem que são apresentadas em determinadas áreas do Website. Um pedido de imagem grande é mais rápido do que vários pedidos de imagem pequena.
Utilizar uma RFC (rede de fornecimento de conteúdo)
Uma rede de funcionamento de conteúdo é uma excelente forma de proporcionar mais velocidade ao seu Website, tornando-o, ao mesmo tempo, mais escalável e fiável. Trata-se de distribuir os ficheiros e o conteúdo acedidos frequentemente a partir do seu Website e colocá-los em vários servidores de todo o mundo.
Normalmente, um serviço de alojamento na Web está situado numa localização física fixa, por exemplo, na Califórnia. Isto não representa um problema para os utilizadores da Califórnia, pois recebem o conteúdo do seu Website rapidamente, mas e os utilizadores que se encontram na Austrália ou na Europa? Ficarão sujeitos a uma maior latência ao aguardar pelos ficheiros da Califórnia, mas através de uma RFC esses utilizadores podem receber os ficheiros a partir de um servidor mais próximo das suas localizações físicas.
Ao distribuir o seu Website em vários servidores de todo o mundo, será também menos afetado(a) por falhas ou outros problemas de infraestrutura.
Uma RFC é ótima para conteúdo que normalmente permanece estático ou não muda com frequência, como os seus ficheiros JavaScript, CSS, HTML e imagens ou conteúdo de vídeo. A RFC comprime também estes ficheiros para o tamanho mais pequeno possível ao remover o espaçamento entre linhas nos ficheiros JavaScript, CSS e HTML.
A Google oferece seu próprio serviço RFC que se designa por Google PageSpeed.
Comprimir ficheiros HTML, CSS e JS
Se não pretender utilizar um serviço RFC (acima mencionado), pode também encontrar vários módulos, plug-ins e serviços Web gratuitos que comprimem automaticamente o conteúdo ao remover o espaçamento entre linhas e ao agrupar vários ficheiros (por exemplo, ficheiros CSS) num único pedido.
Pedidos de cache populares
Uma pilha de servidor Web popular utiliza o Linux Apache MySQL PHP (LAMP).
No diagrama acima, podemos ver que são de facto necessários vários passos para devolver ao utilizador uma página convertida em HTML:
- O servidor Web recebe o pedido
- Em seguida, o servidor Web envia o pedido via PHP, que decide a que ficheiros ou linhas da base de dados aceder
- O PHP processa tudo isto e compila a página HTML relevante que é enviada em seguida a um utilizador
Como a colocação em cache pode ajudar
Em muitos casos, o conteúdo das suas páginas não muda sempre que um utilizador solicita a página, por exemplo, uma página de perguntas frequentes. Em vez de passar por todo o processo do diagrama acima, podemos compilar a página uma vez e colocá-la na cache como um ficheiro HTML temporário. Isto evita que o servidor Web tenha de repetir a tarefa de gerar uma página via PHP e consultar uma base de dados vezes sem conta. Em vez disso, é apresentado um ficheiro HTML estático à maioria dos utilizadores. Desta forma, liberta o servidor Web de operações multitarefa constantes e o seu Website ganha velocidade para todos.
Estão disponíveis vários módulos gratuitos que executam esta tarefa para o seu Website.
Embora o PHP tenha servido de exemplo acima, muitos outros servidores Web funcionam segundo um princípio idêntico e terão provavelmente disponíveis módulos semelhantes para realizar esta forma de colocação de páginas em cache.
Ponderar o uso de Ajax e de plug-ins, como o Infinite Scroll ou o Lazy Load, para Jquery
Alguma vez reparou que determinados Websites carregam conteúdo à medida que desloca a página para baixo? O YouTube fá-lo para miniaturas de vídeos relacionados e a secção de comentários está limitada aos primeiros resultados, a não ser que solicite a apresentação de comentários adicionais.
A utilização adequada destas técnicas pode reduzir o pedido do tamanho de página inicial e permitir que os utilizadores comecem a interagir com as suas páginas de imediato. Se desejarem ver mais conteúdo, podem deslocar-se ainda mais e acionar itens adicionais a carregar.
Quando implementar este tipo de solução, há vários problemas de capacidade de utilização e de acessibilidade a ter em conta. Consulte a documentação do LazyLoad e do InfiniteScroll para obter mais informações.
Compressão Gzip
Os navegadores de Internet mais antigos não suportavam esta forma de compressão de páginas (HTML, CSS, JavaScript, etc.), mas os navegadores mais recentes, incluindo os dispositivos móveis, suportam-na. O melhor desta funcionalidade é a sua simplicidade e facilidade, que lhe permitem tirar o máximo partido.
Saiba mais sobre o Gzip neste vídeo.
Atualizar para o Universal Analytics
Se ainda não efetuou a atualização do Classic (ga.js) para o Universal Analytics (analytics.js), poderá pretender migrar para a plataforma mais recente do Analytics. Para além de passar a ter acesso às funcionalidades do produto mais recentes, o Universal Analytics dispõe de alguns melhoramentos que deve ter em conta:
- Biblioteca de códigos de acompanhamento com base em módulos: o analytics.js tem módulos externos, como o comércio eletrónico, que deixaram de ser incluídos para todos os Websites (que corresponde à forma como o ga.js funciona). Isto reduz a pegada do analytics.js em termos de tamanho de ficheiro, o que se traduz numa maior velocidade de transferência de ficheiros.
- Redução da dependência dos cookies: o Universal Analytics calcula os dados relativos a campanhas e sessões do lado do servidor (e não do lado do cliente), o que reduz a quantidade de dados de cookies transferidos por cada pedido de ficheiro. Este facto constitui uma otimização pequena, mas visível do desempenho.
Servidores de alojamento da Web mais rápidos
Poderá estar a perder oportunidades de negócio por causa de um Website lento. Vale a pena considerar uma atualização para um servidor de alojamento da Web mais rápido.
Mais conselhos e sugestões
Este artigo não consegue abranger todas as técnicas de otimização disponíveis, mas podemos direcioná-lo(a) para muitas mais. Consulte esta documentação para obter conselhos e sugestões adicionais.
Por último, tenha em conta que pode melhorar a velocidade e a capacidade de resposta do seu próprio Website. No entanto, a dada altura, pode deparar-se com problemas provocados por ligações à Internet lentas e redes móveis lentas dos utilizadores. Este é um problema que se verifica mais em zonas rurais e remotas e nos países em desenvolvimento com infraestruturas de telecomunicações limitadas ou antigas.
O melhor a fazer nessas circunstâncias é tornar o seu Website o mais dinâmico possível, embora mesmo o Website mais otimizado possa obter cliques curtos devido à lentidão das ligações dos utilizadores.
