Armazenando em cache usando o wget

Uso o drupal 7. Depois de limpar o cache, uso o wget assim para armazenar em cache todas as páginas de volta.

wget --quiet http://xxx.xxx/sitemap.xml --output-document - | egrep -o "http://xxx.xxx[^<]+" | wget -q --delete-after -i -

Depois de feito, eu verifico no banco de dados a tabela cache_page, e todas as páginas parecem estar lá. No entanto, se eu visitar qualquer página do navegador, isso leva tempo como se não tivesse sido pré-armazenado em cache. O que notei também é que, depois de visitar a página no navegador, o tempo de carregamento na próxima visita é muito rápido, como deveria ser.

Qual pode ser o problema? Estou usando esse método com êxito em uma página do Drupal 6 sem problemas. O log de erros não mostra nada, exceto o favicon.ico não existe.

O log de acesso para URLs é semelhante ao seguinte:

www.xxx.sk 11.116.206.232 - - [01 / Jan / 2013: 18: 09: 12 +0100] "GET / myurl HTTP / 1.1" 200 31532 "-" "Wget / 1.13.4 (cygwin)"

Eu não estou logado

EDIT: Eu atualizei a versão drupal 7.14 para 7.19, mas nenhuma alteração. Depois de examinar a tabela cache_page, notei que todas as páginas visitadas usando o navegador são geradas por algum motivo estranho com _900 no final, assim: www.example.com/examplepath_900. Eu não havia notado isso antes porque os caminhos não cabem dentro das células nas tabelas do banco de dados. É por isso que as páginas não são armazenadas em cache. Também configurei uma instalação nova do drupal 7 no mesmo host em que o cache usando o wget funciona conforme o esperado, sem problemas. Não pode haver problema no htaccess ou nos arquivos de configurações também. Talvez algum módulo instalado possa causar isso?

Todos os navegadores modernos enviam algum cabeçalho Accept-Encoding ~ 'gzip', para que as entradas em cache não sejam usadas se o seu spider não o usar (um back-end decente que gera respostas compactadas em gzip adiciona um cabeçalho de variação: Accept-Encoding). Você também pode procurar na opção --mirror do wget, que pode ajudar aqui.

O conselho de Kenny é sólido. Uma outra idéia é que você pode ter vários ativos que estão sendo armazenados em cache no navegador no primeiro carregamento e depois no segundo. Em vez de fazer o teste no mesmo navegador, tente fazer o teste em uma janela anônima do Chrome, fechando a janela e, em seguida, faça-o novamente. Isso deve ajudar a determinar se a falha do cache da página Drupal em atender à solicitação (talvez por causa da ideia do Gzip) é responsável pela lentidão ou se o cache de arquivos do navegador faz com que eles não façam o download novamente, o que torna a segunda solicitação mais rápida.

Esse problema foi causado pelo módulo http://drupal.org/project/resp_img após a instalação da versão mais recente, está tudo ok.