SEO e SEM:

Caracterização do Acesso à Internet – acesso fixo versus acesso móvel4 (nº de clientes)

De acordo com a ANACOM, os acessos móveis à Internet têm vindo a crescer de forma sustentada em Portugal, ultrapassando no final de 2008 os acessos fixos.

Note‐se no entanto que dos cerca de 2,4 milhões de utilizadores registados nos acessos móveis no final de 2008, apenas cerca de metade é considerado activo, ou seja, só perto de 1,2 milhões acederam à Internet em banda

larga móvel pelo menos uma vez no trimestre em análise.

Fonte: ANACOM (Informação Estatística do Serviço de Acesso à Internet 2009)


Jose Leite SEO | SEM: Partilhar

SEO | SEM | Web marketing em Portugues

jose leite seo : Noas festas
Boas Festas e Feliz Ano Novo
Merry Christmas
Gesëende Kersfees
Idah Saidan Wa Sanah Jadidah
Feliz Navidad
Tchestita Koleda
Bon Nadal i un Bon Any Nou!
Kung His Hsin Nien bing Chu Shen Tan
Gun Tso Sun Tan'Gung Haw Sun
Feliz Navidad y Próspero Año Nuevo
Sretan Bozic
Prejeme Vam Vesele Vanoce a stastny Novy Rok
Glædelig Jul
Mo'adim Lesimkha
Hyvaa joulua
Joyeux Noel
Kala Christouyenna!
Mele Kalikimaka
Selamat Hari Natal
Nollaig Shona Dhuit
Shinnen omedeto. Kurisumasu Omedeto
Natale hilare et Annum Faustum!
God Jul, or Gledelig Jul
Wesolych Swiat Bozego Narodzenia or Boze Narodzenie
Sarbatori vesele
Pozdrevlyayu s prazdnikom Rozhdestva is Novim Godom
Hristos se rodiSlovakian - Sretan Bozic or Vesele vianoce
Sretam Bozic. Vesela Nova Godina
Vesele Vianoce. A stastlivy Novy Rok
Vesele Bozicne. Screcno Novo Leto
God Jul and Ett Gott Nytt År
Noeliniz Ve Yeni Yiliniz Kutlu Olsun
Srozhdestvom Kristovym
Kellemes Karacsonyi unnepeket

José Leite

Jose Leite SEO | SEM: Partilhar

Ferramentas Analytics para Twitter

Ferramentas Analytics para Twitter
  • Medir a Influência no Twitter
Klout Score, funciona como um proxy de influência (pelo Avinash).

Klout Jose Leite SEOKlout Jose Leite SEO
Mais do que o mapa de posicionamento de influência, as metricas apresentadas são extremamente úteis para gerir o seu twitter, baseada nos critérios definidos aqui.
  • Monitorizar os seus seguidores legitimos
GraphEdge, através de uma definição interessante de ligitimidade.


GraphEdge jose Leite SEO
  • Uma análise linguística do twitter
tweetpsych, os seus twitte's não são nem devem ser medidos por volume e retwitting, ou ainda por followers. Uma boa forma de se aproximar e perceber quem tende a ter o seu comportamento linguístico é utilizar esta aplicação e assim poder adicionar mais uma metrica aos seus cálculos.
Exemplo:

Cognitive Content

Primordial, Conceptual and Emotional Content


  • Analize as palavras mais associadas à sua pesquisa (a um determinado termo)
Twitter Stream Graphs, uma óptima ferramenta gráfica para o auxiliar a entender melhor os conteúdos associados e os volumes por palavra.

Twitter Stream Graphs Jose Leite SEO
Jose Leite SEO | SEM: Partilhar

Como diminuir o tempo de carregamento de uma página?

Olá a todos. Depois de perceber que existem dúvidas na forma de optimizar o tempo de resposta de um site, e porque te influência em termos de page rank e usabilidade decidi criar este post, que embora extenso, pode ajudar qualquer um a fazer melhorias e verificá-las posteriormente de uma forma fácil. Desculpem pelo tamanho mas julgo melhor desta forma.


  1. Optimizar a página para caching

Muitas páginas Web incluem recursos que não mudam frequentemente, como por exemplo ficheiros CSS, imagens, Javascript, …

Estes recursos demoram tempo a ser descarregados através da rede, o que irá incrementar o tempo de carregamento da página. http caching permite que estes recursos sejam gravados ou fiquem na cache de um browser ou proxy. Se o recurso estiver na cache, o browser ou o proxy podem referir-se a esta cópia em cache em vez de descarregar os ficheiros de novo. Se isto não acontece em visitas sucessivas, então serão sempre descarregados em cada visita! Esta forma, permitir que os ficheiros fiquem em cache é uma jogada com vitória a dobrar: reduz o round-trip-time eliminando vários http requests (pedidos ao servidor), e reduz o tempo de resposta do servidor (Payload Time).

  1. Browser caching

Definir uma data de expiração ou um máximo de idade no cabeçalho do http para recursos estáticos permite ao browser carregar previamente recursos anteriormente descarregados a partir de um disco local em vez de utilizar a rede para o fazer.

http suporta cache local de recursos estáticos pelo browser. Em todo o caso, a não ser que o servidor indique que determinado recurso poderá ficar em cache, o browser poderá assumir que o recurso não ficará em cache e repetir os pedidos sucessivos ao servidor por esses recursos em cada visita. Para tirarmos vantagem dos benefícios da cache, teremos de dar a instrução ao servidor para definir os headers http e aplicá-los a todos os recursos estáticos.

Os recursos que deverão ficar em cache são:

  • JS
  • CSS
  • Imagens
  • PDF's
  • Flash's

O HTML não é estático nem o deve ser, por isto não deve por si só ser considerado para ficar em cache.


HTTP/1.1 oferece-nos as seguintes respostas do cabeçalho:

  • Expires e Cache-Control:Max-age – especificam o tempo de vida actualizado de um determinado recurso. O período de tempo enquanto este recurso poderá ficar em cache, sem a necessidade de validação se existe ou não uma nova versão no servidor. Importante é perceber que ao utilizar estes cabeçalhos, o browser nunca irá assumir um pedido GET ao servidor até que esta data se verifique ou que a idade máxima seja atingida.
  • Last-Modified e eTag: especificam algumas características que o browser valida para determinar se os recursos são os mesmos.
    O cabeçalho Last-modified é sempre uma data. O cabeçalho e-Tag pode ser um valor qualquer, desde que identifique univocamente o recurso em questão (versão do ficheiro ou hash-code são típicos para o e-tag). Last-modified é um cabeçalho fraco ao qual o browser aplica um método heurístico para determinar se coloca em cache ou não. Estes métodos heurísticos variam de browser para browser. Seja como for estes cabeçalhos permitem fazer pedidos GET condicionais (caso exista um refrescamento da página por exemplo) mas mesmo assim o servidor não devolve uma resposta completa se a versão no servidor for igual, o que reduz o tempo de latência relativamente a um pedido GET completo.

Assim, é importante especificar um dos dois: Expires ou Cache-Control: Max-age e ainda um dos dois: Last-modified ou e-Tag para todos os recursos estáticos. Importante e ainda realçar que é redundante a utilização simultânea de todos.

As minhas recomendações:

  • Defina Expires como mínimo de um mês e até um ano. Prefiro expires a cache-control:Max-age porque é mais largamente aceite. Não o defina por mais de um ano pois viola as regras RFC. Caso saiba exactamente quando um recurso vai mudar, então defina uma data curta, se não souber defina uma data longa.
  • Defina a data Last-modified para a data em que o recurso foi alterado pela última vez.
  1. Proxy caching


Ao permitir publicamente que os seus recursos podem ficar em cache nos proxy's, significa que até novos visitantes poderão beneficiar do facto destes recursos estáticos estarem na cache de proxy's. Basta que já tenha sido efectuado um pedido através de um proxy que depois não voltará ao servidor para responder a pedidos idênticos. Dado que a lógica do proxy também é a proximidade, isto irá reduzir bastante o tempo de latência.

Utilize o cabeçalho Cache-Control:public para indicar que um determinado recurso poderá ficar em cache nos proxy's públicos, e nos browsers que façam o pedido. Com algumas excepções deverão configurar o servidor para que se tornem publicas as permissões de cache.

Excepções:

  • Não inclua parâmetros (querystrings) nos URL's para recursos estáticos
  • Não permita que recursos que utilizem cookies tenham permissões públicas de cache
  1. Minimizar Round-trip Time (tempo de ida e volta: pedido e resposta)


O RTT é o tempo que demora para que um cliente envie um pedido ao servidor, e ainda o tempo que este demora a responder a esse mesmo pedido (sem incluir o tempo de transferência de dados). Isto é, inclui o tempo de back-end e preparação e exclui o tempo de transferência de dados entre cliente e servidor.

Por exemplo:

Um browser quer iniciar pela primeira vez uma conexão com o servidor. Devem ocorrer no mínimo 3 RTT's:

  • RTT para DNS
  • RTT para definir a conexão TCP
  • RTT para o pedido http e para o primeiro byte da resposta.

É preciso perceber que muitas páginas necessitam de vários RTT's.

Desta forma é fundamental diminuir estes tempos para aumentar a performance. Como fazê-lo?

  1. Minimizar DNS lookup

Reduzindo o número de servidores únicos a partir dos quais os recursos são acedidos corta o número de DNS resolution que o browser tem de fazer, e consequentemente os atrasos de RTT.

As minhas recomendações:

  • Utilize URL's em vez de servidores sempre que possível. Por exemplo, é preferível colocar o site em www.dominio.pt/directorio ao invés de directorio.dominio.pt.
  • Coloque os ficheiros Javascript no mesmo servidor. Desta forma evita-se o acesso a caminhos críticos (critical paths) que são os recursos necessários para o render da página. Ao reduzirmos estes caminhos críticos em termos de DNS resolution e ainda ao conseguirmos que o tempo de render do javascript aumenta, e assim, evita-se o efeito de bloqueio de recursos enquanto faz o render do javascript.
  1. Minimizar redireccionamentos

Ao minimizarmos os redireccionamentos de um URL para outro estamos a eliminar RTT's adicionais e assim optimiza-se o tempo de espera dos utilizadores.

As minhas recomendações:

  • Elimine todos os redireccionamentos desnecessários do site
    • Não faça redireccionamentos em cascata AàBàC
    • Minimize o número de redireccionamentos entre domínios
  • Utilize as funções de reescrita do servidor para URL de utilizadores
  • Utilize redireccionamentos 301 (permanentes)

  1. Combinar Javascript's externos

Combine vários Javascript's em apenas alguns ficheiros de forma a reduzir os RTT e atrasos ao descarregar os ficheiros. Não se esqueça que os ficheiros são descarregados sequencialmente.

As minhas recomendações:

  • Crie dois ficheiros javascript: um com os dados para o render básico da página e outro com o restante código (sempre no mesmo servidor)
  • Carregue os Javascript's apenas e quando necessário
  • Para as pequenas partes de javascript que não devam ficar em cache, coloques directamente no código
  • Tenha atenção à ordem com que os ficheiros são colocados no <head> pois será por essa ordem que serão carregados


  1. Combinar CSS externos

Combine vários CSS's em apenas alguns ficheiros de forma a reduzir os RTT e atrasos ao descarregar os ficheiros.

As minhas recomendações:

  • Crie dois ficheiros CSS: um com os dados para o render básico da página e outro com o restante código (sempre no mesmo servidor)
  • Carregue os CSS's apenas e quando necessário
  • Para as pequenas partes de CSS que não devam ficar em cache, coloques directamente no código
  • Evite o uso da regra @import nos ficheiros CSS
  • Tenha atenção à ordem com que os ficheiros são colocados no <head> pois será por essa ordem que serão carregados

  1. Minimize o tamanho dos cookies

Manter os cookies o mais pequenos possível assegura que um pedido http poderá ser efectuado num único pacote de dados.

As minhas recomendações:

  • Utilize a memória do servidor para a maior parte do tamanho de payload (apenas id é guardado no cookie)
  • Remova os campos duplicados nos cookies
  1. Sirva os recursos estáticos a partir de domínios sem cookies

Isto reduz o número de pedidos efectuados ao servidor para uma determinada página.

As minhas recomendações:

  • Permita proxy-caching (public) – sem cookies não existe problema de cache
Teste aqui !!

Jose Leite SEO | SEM: Partilhar

Google Zeitgeist 2009

A Google publicou os resultados de 2009 do Google Zeitgeist. São as palavras mais pesquisadas do ano de 2009, representando:
  • pessoas
  • eventos
  • recordações
Veja mais resultados no site do Google Zeitgeist.
Pena é que não exista o segmento regional de portugal, sendo assim temos de nos basear em dados globais e disfrutar deles.

Abraço
José Leite

Jose Leite SEO | SEM: Partilhar

Os Cookies do Google Analytics

O que são os cookies?

Cookies são ficheiros de texto, até 4095 bytes, que são utilizados pelos browsers e pelos servidores. Sem estes ficheiros, o servidor não consegue diferenciar pessoas que já visitaram o site ou não, guardar informações acerca da sua navegação, bem como as páginas que foram visitadas, dados do browser do utilizador, etc.

Os cookies não identificam pessoas, só armazenam os dados relativo à sua navegação. Outro ponto interessante a ser lembrado é que somente o domínio que gravou este cookie é que o pode ler. Por exemplo se um cookie é gravado quando o visitante vai ao site http://www.dashofer.pt, somente o domínio “dashofer.pt” pode ler os dados gravados nestes cookies e de mais nenhum outro domínio.

A RFC2109 especifica como os browsers devem tratar os cookies, a quantidade mínima de cookies que um browser pode suportar, apesar de alguns terem um suporte maior, são:

  • Total de cookies - 300 para todos os domínios visitados
  • Total de cookies por domínio - 20

Os cookies podem ser divididos de acordo com o tempo que se mantém activos em:

  • Cookies de sessão - após 30 minutos de inactividade ou pelo encerrar do browser este tipo de cookie é apagado.
  • Cookie permanente - este tipo de cookie mantém-se gravado mesmo após o término da sessão. Apenas permanecem activos durante um tempo pré-determinado pelo servidor que irá ler estes dados no futuro, vejam os exemplos abaixo do Google Analytics.

Também são divididos de acordo com o domínio em causa:

  • First Party Cookie - é o mais aceite pelos browsers nas configurações de segurança, ele é gravado pelo domínio.
  • Third Party Cookie - é quando outro domínio grava um cookie quando. É usado pelos Ad´Servers, por exemplo, para identificar quantas vezes umas determinadas banner foi clicado, mesmo estando em vários domínios diferentes. Dependendo da configuração de segurança do browser, pode não ser gravado.

Os Cookies do Google

O Google Analytics trabalha com 6 cookies:

  • _utma - Identifica os visitantes únicos - Cada browser guarda um único cookie deste tipo com um ID único que permite verificar se este visitante já esteve anteriormente no site. Duas situações: a primeira é que se mais de uma pessoa usar o mesmo PC o site irá identificar todos os diferentes utilizadores como sendo o mesmo, e, no caso de o utilizador utilizar vários browsers, este poderá ser identificado como diferentes utilizadores, já que cada browser terá o seu grupo de cookies. Este cookie tem uma permanência de 2 anos após sua gravação.
  • _utmb e _utmc - Identificação da sessão - Trabalham em conjunto para identificar se é uma sessão nova, o inicio de uma sessão e o tempo total de visita. Sendo que a última página visitada, ou no caso de bounces a única página visitada, não tem o seu tempo contabilizado pelo Google Analytics no tempo total de permanência na página. È através do _utmc que o Google Analytics verifica se o tempo de permanência num determinado site sem actividade passou de 30 minutos e inicia uma nova sessão (visita) se houver alguma actividade. O tempo para expirar é de 30 minutos de inactividade ou, caso o visitante feche o browser. Este tempo de 30 minutos pode ser alterado pelo pageTracker._setSessionTimeout(”tempo em segundos”).
  • _utmv - Identificação de segmento do utlizador. Este cookie é gravado quando definimos o pageTracker._setVar(“segmento”) para criar uma segmentação para os utilizadores. Como no caso do _utma, o cookie permanece activo por 2 anos após ser gravado.
  • _utmz - Identifica as variáveis de campanha.Este cookie tem validade até 6 meses a partir da data de criação. A informação gravada pode ser modificada pelo _utm_nooverride. Este cookie pode ter o tempo de expiração alterado no pageTracker._setCookieTimeout(”tempo em segundos”)
  • _utmx - Utilizado pelo Google Website Optimizer - É utilizado para que o GWO possa identificar que página foi recebida pelo utilizador durante um teste A/B, A/B/n ou Multivariável, para que durante o teste ele receba sempre a mesma página e não uma outra variante. Este cookie mantem-se activo por 2 anos.

Cookies do Google

Os campos dos cookies são delimitados por “.”, assim temos:

  • _utma - Código do dominio.ID do visitante.tempo inicial da visita.numero de vezes que visitou o site
  • _utmb - Código da sessão
  • _utmc - Código da sessão
  • _utmv - ID do visitante.Segmento
  • _utmx - Variante do conteudo.Sessão
  • _utmz - ID do visitante. xxx . xxx. x.utmcsr=origem da campanha|utmccn=nome da camapanha|utmcmd=meio da campanha|utmctr - palavras chaves da campanha|utmcct=conteúdo da campanha

Esta é a parte mais técnica do Google Analytics e a mais desconhecida.

Bom trabalho a todos,

José Leite


Jose Leite SEO | SEM: Partilhar

Usabilidade: Medição e análise da Web

Medição e análise da Web

Uma das ferramentas que me intrigou quando a descobri foi FiveSecondTest.com, encarada como uma ferramenta de teste de usabilidade em cinco segundos. Literalmente podemos carregar uma imagem de uma página Web e, em seguida, escolher:

memory test (teste de memória) – Do que se lembra do projecto

a click test (clique em todos os elementos que lhe parecem clicáveis).

Há algumas pequenas despesas associadas com diferentes níveis de teste.


Teste já o seu site e poderá tirar conclusões importantes para o negócio.


Jose Leite SEO | SEM: Partilhar