I use drupal 7. After clearing the cache, I use wget like this to cache all pages back.

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

After it is done, I check in database the cache_page table, and all pages seems to be there. However, if I visit any page with the browser, it takes time as if it was not pre-cached. What I noticed as well is that after visiting the page in browser, the loading time on next visit is very fast as it should be.

What can the problem be? I am successfully using this method on a Drupal 6 page with no problems. Error log shows nothing except favicon.ico does not exist.

The access log for URLs looks like the following:

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

I am NOT logged in

EDIT: I updated drupal 7.14 to 7.19 version but no change. After looking into cache_page table I noticed that all pages visited using browser are generated for some strange reason with _900 at the end like this: www.example.com/examplepath_900. I did not noticed it before because the paths don't fit inside the cells in database tables. So that is why pages are not cached. Also I set up fresh installation of drupal 7 on the same host where caching using wget works as expected with no problems. There can not be problem in htaccess or settings files as well. Maybe some installed module can cause this?

  • Where are you doing this from? The same server, or another server?
    – mpdonadio
    Commented Jan 1, 2013 at 15:42
  • @MPD I use cygwin terminal to run wget. However, my drupal 7 page is hosted with another provider that my drupal 6 site
    – loparr
    Commented Jan 1, 2013 at 16:13
  • Can you view HTTP headers? After you run the script, check the headers and look for one like "X-Drupal-Cache: Hit". I forget the exact header name, though.
    – mpdonadio
    Commented Jan 1, 2013 at 16:45
  • @MPD I cleared the cache, ran the script,cache_page table shows all links but I found X-Drupal-Cache:MISS in headers of all newly visited pages.
    – loparr
    Commented Jan 1, 2013 at 17:13
  • Are you testing as an authenticated user? If so, the page cache won't be hit. Commented Jan 1, 2013 at 23:17

3 Answers 3


All modern browsers send some Accept-Encoding ~ 'gzip' header, so cached entries will not be used if your spider doesn't use this one (a decent back-end generating gzipped responses adds a vary: Accept-Encoding header). You may also look into the --mirror option of wget which could assist here.

  • If webkenny says something about Drupal performance, I'm assuming it's true. +1.
    – Letharion
    Commented Jan 11, 2013 at 10:47
  • 1
    For core, the gzip header shouldn't matter. drupal_serve_page_from_cache()
    – mikeytown2
    Commented Jan 11, 2013 at 20:27

Kenny's advice is solid. One other idea is that you may have several assets that are being cached in the browser on the first load and then not the second. Instead of doing the test in the same browser, try doing the test in a Chrome Incognito window, closing that window, and then doing it again. That should help determine if it is the Drupal page cache's failure to fulfill the request (maybe because of the Gzip idea) that is responsible for slowness or if it is browser caching of files causing them not to download again which makes the second request faster.


This issue was caused by module http://drupal.org/project/resp_img after installing the latest version, everything is ok.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.