Here’s a pretty short lived setup… ensuring .php is not cached. You will have to wait until the current caching expires, or use a new browser / log in as someone else…
ExpiresActive On
Images cached for a day…
ExpiresByType image/gif “access plus 1 day”
ExpiresByType image/png “access plus 1 day”
ExpiresByType image/x-icon “access plus 1 day”
I do have mod_expires loaded and apache is set to allow processing htaccess.
You mention waiting “until your current caching expires or use another web browser…”. Why would I need to wait on the caching to expire? If I am making the changes to .htaccess, flush the cache on my Backend, and then run the webpage test, should the results not reflect those changes on that subsequent test?
I thought ‘no way that one setting changed that’. So I changed it back to 1sec, and still came up with FAAAC.
I noticed that in the run that reported the FAAAA, it sent css files and not php files like subsequent & prior test. I also noticed that with the FAAAA test, the TTFB was 0.812s - down from the normal ~2.5s. Huh?
My guess is that you have a plugin that optimizes/combines the resources and it didn’t kick in on the first test but when it did kick in you got the .php resources.
The idea of having an expiry date on a file is that is is stored on your browser until the expiry time, so will not attempt to download the file (or even check) until that time expires.
So changes to the backend / .htaccess are irrelevant. It has it and knows when it’s valid until. Look at the repeat waterfall on this very site for an example.