Only cache misses with pagespeed


#1

I’ve noticed in the pagespeed statistics it always reports a cache miss, no cache hits. If I check the /var/ngx_pagespeed_cache directory nothing is being stored there by pagespeed. My configuration is almost a completely default easyengine install with wordpress and pagespeed. The only change I made was setting up ssl. Could it be a permission problem on ngx_pagespeed_cache directory? Since everything is configured by default I assume no one that is installing pagespeed with easyengine has the cache working properly. Has anyone checked to see if the pagespeed cache is working correctly? For now I’m going to disable it until I can figure it out.


#2

I’m kind of at a loss. The only way I can get pagespeed to write to the ngx_pagespeed_cache directory is if I set 777 permissions like this drwxrwxrwx 3 www-data www-data 4096 Jun 2 17:11 /var/ngx_pagespeed_cache. I don’t know if this is safe, but for now I guess I’ll just leave the permissions like that so it will work. I would assume anyone using easyengine would have this problem, let me know if anyone knows the proper permissions for pagespeed to write to it’s cache directory. Thanks.


#3

Refer to here, basically Rahul says that pagespeed does not cache with ngnix fast cgi cache.


#4

@rsmith4321 you may check - https://github.com/rtCamp/easyengine/issues/497

We have disabled pagespeed on all our sites for now. I am glad that we did not make it default.

As of now I am experimenting with https://wordpress.org/plugins/autoptimize/ plugin for CSS/JS minify and combine. I am very impressed with results so far.

If autoptimize plugin works nicely, we may add it in EasyEngine.

We are also testing some other nginx caching options. It’s too early to say if they will work with pagespeed or not - https://github.com/rtCamp/easyengine/issues/510


#5

Thanks, I’ve disabled it as well. I’m currently using the minify settings in w3tc, since I optimize my images anyway I think that mostly does what pagespeed was doing, and the site seems to respond quicker.


#6

Rahul,

What settings do you have for autoptimize, w3tc and nginx-fast cache. It seems that W3TC would do db and object cache only (to memcached) and autoptimize does the minification / combine?

Does W3TC with Autoptimize have W3TC’s page cache set on on a site with --wpfc?


#7

I am not using W3TC at all.

So far I have tested only following:

I will use “Generate data: URIs for images?” as well.


#8

Interesting, are you using anything for DB and/or Object Caches?


#9

Just from some experimenting I’ve been doing, I seem to get faster load times without w3tc caching anything. I’ve switched to just wpfc and I’m getting around 500ms load times with lots of images, I don’t know how much faster it can get.


#10

By the way, how do you configure nginx to work with autooptimize. I assume there needs to be some configuration in the nginx.conf file to look for the optimized files that are created. Thanks.


#11

This is old topic but I just want to update PageSpeed users.

Please check - https://easyengine.io/blog/disabling-pagespeed/

About autooptimize, we used HTTP2 and it doesn’t need CSS+JS combine/minify. You can try - https://easyengine.io/docs/lets-encrypt/


#12

While HTTP does parallelize the downloads of css and js nicely there is still no reason to not optimize and concatenate css and JS files.


#13

Can you explain what do you mean exactly?

If you mean compression to reduce it’s size, it’s handled by gzip since beginning. If you mean minification, either it can be handled by WordPress for third party assets or developer themselves by using proper dev workflow e.g. gulp/grunt.

If you mean both then there is not significant benefit worth spending time on pagespeed.

You may read - https://css-tricks.com/the-difference-between-minification-and-gzipping/

If you mean something else, please elaborate.

The impact of this is reduced by http/2.

I am reading more on the topic but in any case, we wont be adding pagespeed back.


#14

Just to be clear, I am not suggesting using pagespeed for anything :slight_smile:

I am saying we should not get complacent or lazy and not optimize CSS and JS files by combining, minifying and gzipping just because of HTTP/2.

Yes, developers should provide minified versions for their themes and plugins. Absolutely. Then we should combine them, place them appropriately in header or footer, defer or async the javascript appropriately etc.

I completely agree with you that we should not spend time on the pagespeed module.


#15

Great. :slight_smile:

I personally inclined to avoid concatenate also.

Different people have different opinions.

I mostly agree with https://blog.cloudflare.com/http-2-for-web-developers/

For own WordPress theme and plugins - we use grunt to bundle only 1 css/js per theme/plugin. This 1 css/js is minified and concatenated at that theme/plugin level.


#16

I know concatenation can sometimes mess with the CSS so it breaks the layout, but I still think it should be done where possible since performance analysis services will always complain about the number of HTTP requests despite HTTP/2’s presence.

And of course HTTP2 is only working over SSL despite it not being necessary. Many site owners don’t see the need to switch to HTTPS since it comes with performance overhead for very little SEO benefit in Google.

When clients see 100 requests that could be 60 and not break anything on the site, I think it’s something worth doing.

I wish all developers used grunt to minify.


#17

SSL doesn’t take considerable resources. Nginx also has SSL session cache to further improve performance.

In fact SSL + HTTP/2 is better than plain HTTP.

About performance analysis services - don’t follow them blindly. You can ignore false recommendations. I stopped using most of such services in favor of HTTP/2.

The only performance area I dig into is PHP+MySQL performance. I mostly use New Relic for it or xdebug - https://easyengine.io/tutorials/php/xdebug-webgrind/


#18

My tests have shown otherwise, SSL just isn’t worth it for me speedwise as it hurts TTFB (50ms vs almost 300ms on the smallest DO VPS). SSL overhead is further exacerbated by distance between the origin server and the receiver. Unfortunately session cache doesn’t help for the initial handshake which is what I’m concerned with.

I agree some performance analysis services do not always give the best advice. I still like minimalism and efficiency so will be concatenating and minifying where possible which will keep my clients happy when they see performance tests.

Does new relic show MySQL slow queries? I use the plugin Query Monitor to identify suboptimal plugins and report the issues to the developers. I prefer to avoid php and mysql almost altogether, Varnish makes this possible :wink:


#19

I’m not sure what you issue is but I use Digital Ocean and I have no delay using ssl. There seems to be almost no overhead at all using http2.


#20

I use my own Xen (and KVM) VPSs on my own dedicated servers, and I never noticed such delays, too.

Http/2 actually makes sites a lot faster for me.