@bonny3 and
@ehrgeiz,
There are some problems with your installations, in the sense that
- some config settings are "double", and/or
- some config settings are wrongly placed, and/or
- compilation of nginx is not quite as it should be, and/or
- future issues can be expected.
First of all, note that the nginx pagespeed module is somewhat unstable. It can break the whole Apache + Nginx stack, due to performance issues (i.e. overloads) and/or buggy code.
Be aware that you have to optimize the Apache + Nginx stack in Plesk manually, in order to minimize the risk of the pagespeed module resulting in errors.
With respect to the "double config settings", the following.
Note that one does not necessarily has to define the gzip and/or header config settings, that can be arranged by the pagespeed settings.
In fact, when using pagespeed settings to determine compression levels and/or set headers, these pagespeed will often prevail (i.e. dominate other settings) or even break the settings in the normal nginx.conf or *.conf files.
When using the pagespeed module, it is adviceable to configure settings with the pagespeed module (and not normal config files), as far as possible.
With respect to the wrong placement of config settings, the following.
Bonny3 stated:
It is NOT the correct place for
- the directive "pagespeed on",
- the pagespeed related location directives,
and NOT the preferred place for gzip related directives.
The proper way to do this is to create a custom config file, by preference located in the /etc/nginx/plesk.conf.d directory (the /etc/nginx/conf.d directory will also work).
After all, the before mentioned directives are server-wide directives, that should be applied to the whole Nginx server.
The actual activation of specific pagespeed filters and similar directives CAN be placed in the domain and subdomain custom config files.
With respect to the compilation of nginx, the following.
Note that the compilation of the pagespeed module into Nginx is easy and certainly, one has to
- use the proper prefixes and file paths,
- be aware that one does overwrite the Plesk provided Nginx packages and standard config settings,
and the above implies that reverting a erroneous Nginx + pagespeed stack can become rather problematic.
Remember that the pagespeed module is still experimental of nature (and many well-known bugs do exist).
Also note that it is possible (and better) to compile some of the standard pagespeed file/config paths into Nginx, but that requires some tweaking (of source code).
With respect to the future issues, the following.
Note that the current pagespeed module for Nginx is in beta, "experimental" as Google calls it.
Any future alpha release will again be followed by a stable release and, each time a release occurs, one has to recompile AND adjust all config settings.
In short, the current pagespeed module is not the best choice.
Also note that the current pagespeed module consists of various components, that are already available in existing (and often more stable) Nginx modules (third-party modules).
Most of the components in the pagespeed module are not working properly and are underperforming, when compared to before mentioned (stable) existing Nginx modules.
Another subset of components in the pagespeed module are not really used or not really usable, in general scenario´s of webhosting.
In short, the current pagespeed module is an overload of new and old components for Nginx, with the factual danger of undermining performance of Nginx.
Finally, the irony is that the pagespeed module is not really valuable in most of the common implementations of Nginx: if and only if Nginx is used as a pure webserver (and that is not the case in Plesk installations), pagespeed becomes a somewhat valuable module for Nginx.
In conclusion, rethink, before adding the pagespeed module to Nginx.
And, if one really does want to (automatically)
- minimify JS and CSS: use perl-based scripts with Nginx (requires perl module for Nginx) OR other scripts (bash, python, perl etc.) with a crontab,
- minimify images: use jpegcrush, jpegtran etc with a crontab,
- defer JS: alter the html and/or php templates, instead of optimizing afterwards (i.e. remove suboptimal code, instead of working around this issue with pagespeed)
and so on.
Regards....