Facebook
Twitter
-
If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
CentOS2Alma discussion
Resolved Do you use WebP image format on your wordpress sites?
- Thread starter Tomek
- Start date
Yes, I use it with pagespeed module for nginx - Archive - Script for building replacement of default sw-nginx Plesk package (CentOS6 ONLY!) 
I would rather have all this added as bacic functionality. That's the whole idea of Plesk.
A supporting webif to control it would complete this.
If this situation continues we will all have nginx binaries created from source and any problem with the system can't have support as it is a "tampered" installation.
These features are things that are wanted by people that like to offer the most recent solution.
By only offering this for a deprecated OS (this script is exclusively for CentOS 6), it can only be useful for an extreme low number of people (an assumption of mine).
People needing this are most likely running either CentOS 7 or some other modern distribution.
It does not matter to me though as I'm using Ubuntu anyhow.
I do have one CentOS 7 server (forced as a deal with Plesk), but I'm running only 1 website there (it's my primary DNS and it creates and distributes DKIM-keys each week for the other servers).
That one is running Plesk 17.8 preview 7. No luck there, either....
I'm hoping to see this changed in the future.
If there is somehow a good reason for Plesk to keep offering only the standard Nginx features I would like to know this as well.
If we know now that this is not going to change any time soon, we can draw our conclusios and start putting some effort in doing this by building an Nginx from source.
It would be a pity if that's the case as it will decrease the added value of Plesk as it is supposed to take care of all this. One can't keep considering these modern extension as an extra feature.
The recent addition of the "pagespeed" extension will even emphasize to our clients (and yours) that they are missing out on some features our hosting is offering them.
I already had a few webmasters ask for support of these modules and told them I wanted to wait for Plesk.
I would still welcome a CentOS 7 and Ubuntu 16.04 script that would offer me a workaround instead of finding out exactly myself.
A supporting webif to control it would complete this.
If this situation continues we will all have nginx binaries created from source and any problem with the system can't have support as it is a "tampered" installation.
These features are things that are wanted by people that like to offer the most recent solution.
By only offering this for a deprecated OS (this script is exclusively for CentOS 6), it can only be useful for an extreme low number of people (an assumption of mine).
People needing this are most likely running either CentOS 7 or some other modern distribution.
It does not matter to me though as I'm using Ubuntu anyhow.
I do have one CentOS 7 server (forced as a deal with Plesk), but I'm running only 1 website there (it's my primary DNS and it creates and distributes DKIM-keys each week for the other servers).
That one is running Plesk 17.8 preview 7. No luck there, either....
I'm hoping to see this changed in the future.
If there is somehow a good reason for Plesk to keep offering only the standard Nginx features I would like to know this as well.
If we know now that this is not going to change any time soon, we can draw our conclusios and start putting some effort in doing this by building an Nginx from source.
It would be a pity if that's the case as it will decrease the added value of Plesk as it is supposed to take care of all this. One can't keep considering these modern extension as an extra feature.
The recent addition of the "pagespeed" extension will even emphasize to our clients (and yours) that they are missing out on some features our hosting is offering them.
I already had a few webmasters ask for support of these modules and told them I wanted to wait for Plesk.
I would still welcome a CentOS 7 and Ubuntu 16.04 script that would offer me a workaround instead of finding out exactly myself.
Last edited:
Version for CentOS7 is much more easy, because there is no problem with gcc version and additional steps for compatibility are not required. Just remove all extra steps from script and install and just follow all nginx/modules related steps.
BTW, there was script for Ubuntu 16.04 from @virtubox - Input - Bash script to compile Nginx from source with additional modules on Plesk Onyx
Partially. This script was written specifically for CentOS 6, because installing a custom nginx with modules is slightly more complicated than for CentOS 7. If necessary, I can write a version of the script for CentOS 7. This script will be much easier, because there will not be anything extra.
After thinking about it, I came to conclusion that I can not use an unsupported Nginx installation.
I decided to switch back to serverpilot.io for projets that require Webp image format.
Thank you Igor for your help and I think, that yours script will help many Pleskians
I decided to switch back to serverpilot.io for projets that require Webp image format.
Thank you Igor for your help and I think, that yours script will help many Pleskians
Last edited:
Yes of course
In the threat below I added a screenshot where you can see the size of images optimized by EWWW Image Optimizer (screenshot-3-png).
Question - EWWW Image Optimizer, WebP format, nginx and Plesk
The webp format do the best job and weighs significantly less than jpg.
Webp is not the next marketing buzzword. It really works.
If you have a lot of graphics on the site, then optimizing them will most speed up yours website.
Yes, but it is supported by the biggest one
WebP Support - It's More Than You ThinkGoogle Speed Module is not just a webp format. These are dozens of features that accelerate your website.
If you do not want to install dozens of worpress plugins, you only have two options:
A) Install Google Speed Module on the server
B) Use a CDN service that has the same features
Last edited:
@Tomek
In response to
you should be aware of the following:
1 - there is always the danger that a (hosting) customer still uses WP plugins, which often conflict with Google PageSpeed module (for Nginx and Apache!)
2 - the Google PageSpeed module is intended for Apache and the Nginx PageSpeed module is still experimental (for many years now): the problem is that using Apache with Google PageSpeed is causing a huge performance penalty for the already memory hungry Apache......... hence reducing any performance improvement of the PageSpeed module itself,
3 - it is quite cumbersome and difficult to configure the PageSpeed module itself, with imperfect configuration often not yielding significant performance improvements,
4 - you forget to mention the options to use Nginx: a default Nginx can do 70% of what Google PageSpeed module can do, whereas a custom compiled Nginx can do 95% of what the Google PageSpeed module can do (as long as the proper Nginx modules are installed).
In general, there are two main factors for making the choice between PageSpeed module implementations OR a CDN:
- costs: PageSpeed module is free, but the significant amount of resources used by Apache's PageSpeed module are not (a better server is often required)
- easy of use: any CDN will be easier to use, since we do not have to do anything
I can recommend the usage of a CDN, since the costs are neglible nowadays and there are some free CDN solutions.
Hope the above helps a bit.
Kind regards..........
In response to
you should be aware of the following:
1 - there is always the danger that a (hosting) customer still uses WP plugins, which often conflict with Google PageSpeed module (for Nginx and Apache!)
2 - the Google PageSpeed module is intended for Apache and the Nginx PageSpeed module is still experimental (for many years now): the problem is that using Apache with Google PageSpeed is causing a huge performance penalty for the already memory hungry Apache......... hence reducing any performance improvement of the PageSpeed module itself,
3 - it is quite cumbersome and difficult to configure the PageSpeed module itself, with imperfect configuration often not yielding significant performance improvements,
4 - you forget to mention the options to use Nginx: a default Nginx can do 70% of what Google PageSpeed module can do, whereas a custom compiled Nginx can do 95% of what the Google PageSpeed module can do (as long as the proper Nginx modules are installed).
In general, there are two main factors for making the choice between PageSpeed module implementations OR a CDN:
- costs: PageSpeed module is free, but the significant amount of resources used by Apache's PageSpeed module are not (a better server is often required)
- easy of use: any CDN will be easier to use, since we do not have to do anything
I can recommend the usage of a CDN, since the costs are neglible nowadays and there are some free CDN solutions.
Hope the above helps a bit.
Kind regards..........
Thank you trialotto for the amazing answer!
I avoid the idea of implementing Google Page Speed Module for shared hosting environment.
At this moment, it does not make much sense, for reasons that you mentioned.
But I use Google Page Speed Module in the VPS Cloud environment. In combination with serverpilot.io, it is something that works for me. After one year of use, I did not experience any big problems, so I will stay with this option (although CDN would be an easier solution as You mentioned).
Dear Plesk Team, it would be great to see a guide for this on blog
I avoid the idea of implementing Google Page Speed Module for shared hosting environment.
At this moment, it does not make much sense, for reasons that you mentioned.
But I use Google Page Speed Module in the VPS Cloud environment. In combination with serverpilot.io, it is something that works for me. After one year of use, I did not experience any big problems, so I will stay with this option (although CDN would be an easier solution as You mentioned).
Dear Plesk Team, it would be great to see a guide for this on blog
Last edited:
@Tomek
You stated
and I must emphasize that it is not that easy to compile Nginx AND make it Plesk compatible at the same time.
The compilation of a custom Nginx is not that difficult, but it will often result in a binary called Nginx........
......... and that makes it a little bit dangerous, when considering upgrade compatibility of Plesk.
In fact, when not changing the binary name at compilation time, the Nginx binary will be replaced by Plesk's default Nginx binary, if Plesk updates are affecting Nginx.
One can specify the binary name at compilation time, so that would be a work-around to prevent most upgrade compatibility issues.
However, even in that case, one still is not completely without problems: there still are some challenges.
In fact, when specifying a custom name at compilation time, one still has the problem that Plesk use a default configuration referring to a binary called "nginx".
In addition, one has the problem that one cannot easily run two Nginx instances on the same system: they will "compete for http requests", potentially resulting in conflicts.
A dirty work-around would be the usage of a symlink with name "nginx" that points to the custom binary.
This symlink based work-around will work until a Plesk upgrade of the Nginx package will occur: the re-creation of the symlink after upgrade is easy.
This dirty work-around is safe: both Plesk's default Nginx binary and the custom Nginx binary can co-exist and are to a large degree upgrade safe.
But it is not an optimal solution.
An alternative is to
a) use a small VPS with a custom compiled Nginx to function as a proxy of all Plesk hosted domains, (or)
b) wait for the moment that Plesk's default Nginx binary finally supports dynamic modules AND all normal Nginx modules are available as dynamic modules, (or)
c) port normal "static" Nginx modules to a dynamic module,
and those alternatives are not really satisfactory.
Personally, I prefer the VPS based alternative, but I do recommend the symlink based (dirty) work-around to start with.
Anyway, I hope the above helps a bit.
And note that this topic is worthy to be posted in a separate topic thread, since the support of custom compiled Nginx instances is a potential future for Plesk.
Regards...........
You stated
and I must emphasize that it is not that easy to compile Nginx AND make it Plesk compatible at the same time.
The compilation of a custom Nginx is not that difficult, but it will often result in a binary called Nginx........
......... and that makes it a little bit dangerous, when considering upgrade compatibility of Plesk.
In fact, when not changing the binary name at compilation time, the Nginx binary will be replaced by Plesk's default Nginx binary, if Plesk updates are affecting Nginx.
One can specify the binary name at compilation time, so that would be a work-around to prevent most upgrade compatibility issues.
However, even in that case, one still is not completely without problems: there still are some challenges.
In fact, when specifying a custom name at compilation time, one still has the problem that Plesk use a default configuration referring to a binary called "nginx".
In addition, one has the problem that one cannot easily run two Nginx instances on the same system: they will "compete for http requests", potentially resulting in conflicts.
A dirty work-around would be the usage of a symlink with name "nginx" that points to the custom binary.
This symlink based work-around will work until a Plesk upgrade of the Nginx package will occur: the re-creation of the symlink after upgrade is easy.
This dirty work-around is safe: both Plesk's default Nginx binary and the custom Nginx binary can co-exist and are to a large degree upgrade safe.
But it is not an optimal solution.
An alternative is to
a) use a small VPS with a custom compiled Nginx to function as a proxy of all Plesk hosted domains, (or)
b) wait for the moment that Plesk's default Nginx binary finally supports dynamic modules AND all normal Nginx modules are available as dynamic modules, (or)
c) port normal "static" Nginx modules to a dynamic module,
and those alternatives are not really satisfactory.
Personally, I prefer the VPS based alternative, but I do recommend the symlink based (dirty) work-around to start with.
Anyway, I hope the above helps a bit.
And note that this topic is worthy to be posted in a separate topic thread, since the support of custom compiled Nginx instances is a potential future for Plesk.
Regards...........