Hi all
Thank's for this great module. It works fine for me on Drupal 6.22.
But... I can't get a good browser cache control for css and js bundles.
They are never cached by the any navigator : response is always 200 ok and never 304 not modified
I tried to modify my .htaccess rules like speficied in previous posts about this issue...
http://drupal.org/node/1334460#comment-5305464
...but I couldnt get a result...
.htaccess generation is disabled.
I use Boost, Memache Api,... Xcache on the server.. mod_expire, mod_deflate
Core performance is disabled.
? ?
Please... help... thanks !
| Comment | File | Size | Author |
|---|---|---|---|
| #5 | advagg-1431668-5-fix-304.patch | 1.85 KB | mikeytown2 |
| #2 | advagg_not_modiefied_304.jpg | 12.68 KB | nadfserver |
Comments
Comment #1
nadfserver commentedThanks for the create modul!
In the first step, I am very happy, as the CSS and JS files are reduced in a big value.
But there is one very critical thing.
The idea of this modul is, to save "power" of the server and send the websites faster to the clients.
There are 2 big views we need to care about:
1) The size of a file
2) The total connection for 1 page.
The modul get it to run for case 1) but the case 2) is broken, see image:
Link to image: http://nadfserver.org/foren/images/misc/advagg_not_modiefied_304.jpg
The following case we have now.
- We are sending smaller files to the clients than before, that's great
- We are sending EVERY time the files to the clients again. That's bad.
Every connection to the server takes time. Now I need to open every time 2 more connections to the server, as the 304 header (not modifed) is not working any more. In default css/js optimizing that is working. To have always 2 more connections to the server than before, breaks the full idea of the modul.
In total it does not make the server/clients calls faster to the website. It makes it slower, for every regulary user (not one time call to the website, then it's faster, but not intresting in total here).
I think the maintainers should take a focus on that bug and yes it's a not a support request as it was requested earlier on that "bug report".
If this can't be solved, the whole need of the modul is not working.
If you need any help from my side to get this fixed, just inform me, I will try my best. But without getting the modified header to 304, this moduls makes in average the website-calling for a user SLOWER not faster.
Don't get me wrong, I really like this modul. But for now it's broken.
I am using Version advagg-6.x-1.9.tar.gz.
Regards
Comment #2
nadfserver commentedhere is image for the "header" check:
Comment #3
peterx commentedI get the same problem with 7.x-2.0-rc2. The response is always 200, not 304. Downloading a copy of one big file is slightly slower than having several 304s in parallel.
I will change the version. Perhaps it can be fixed then backported.
Comment #4
mikeytown2 commentedhttp://stackoverflow.com/questions/499966/etag-vs-header-expires
I have disabled etags by default and rely on expires headers explicitly. From my testing apache doesn't send a 304 if both the "If-Modified-Since" (Last-Modified header) and "If-None-Match" (Etag) header are present. Telling Apache to send a 304 from within .htaccess is also impossible #1413156-1: .htaccess rules for Far Future expiration: make it possible to use the Far Future feature directly in Apache, avoiding PHP.
Looking into the issue more and it appears that both AdvAgg and the CDN module set the "Last-Modified" date in the past. CDN gets around this by using PHP to directly modify the headers when accessing assets inside of the /cdn/ path.
I think the solution for AdvAgg is to remove the custom set Last-Modified header.
More info http://www.webpagetest.org/forums/showthread.php?tid=417
Comment #5
mikeytown2 commentedProblem comes from https://developers.google.com/speed/docs/best-practices/caching
Following this prevents 304s from working correctly.
Following patch has been committed