NGINX / Server Setup

How to install Google PageSpeed (ngx_pagespeed) module for NGINX in CentOS/RHEL 8

by , , revisited on


We have by far the largest RPM repository with dynamic stable NGINX modules and VMODs for Varnish 4.1 and 6.0 LTS. If you want to install NGINX, Varnish and lots of useful modules for them, this is your one stop repository to get all performance related software.
You have to maintain an active subscription in order to be able to use the repository!

NGINX is an open-source web server well known for its high performance and the vast array of features available through modules.

The PageSpeed module for NGINX was developed by Google. Its function is optimizing website static assets as well as HTML output in a way that pages are loaded faster. Some of the techniques implemented by PageSpeed module are:

  • Serving images in next-generation WebP format
  • Minifying CSS and Javascript files
  • Extending cache lifetime (Far Future Expires headers) for static files

The PageSpeed module is available for both Apache and NGINX web servers. The common name is PageSpeed module. It is usually named ModPageSpeed in the context of the Apache webserver. And specifically for the NGINX web server, it is usually named as ngx_pagespeed.

Compile from source? No, thanks

When you need to install ngx_pagespeed, the official documentation is, unfortunately, not your best friend. That is because they recommend compiling from source – a practice very well risky for production servers. Not to say that it will immerse you into a maintenance nightmare whenever either new versions of NGINX or PageSpeed module are released. Compile, recompile.. compile again… Don’t.

Install ngx_pagespeed from a package repository

Meet easy, well-maintained installation of PageSpeed module, available with a couple of dnf commands. And upgrades are only one command away.

You can use our repository to easily install the RPM package of the PageSpeed module for NGINX (ngx_pagespeed).

The dynamic module is compatible with NGINX for CentOS/RHEL 8.

Step 1. Add GetPageSpeed extras YUM repository

First, run the following command to add our repository:

sudo dnf -y install https://extras.getpagespeed.com/release-latest.rpm

Step 2. Install Nginx and ngx_pagespeed

Install latest stable NGINX:

sudo dnf -y install nginx

Then, all you have to do to install the PageSpeed module:

sudo dnf -y install nginx-module-pagespeed

Follow the installation prompt to import GPG public key that is used for verifying packages.

Step 3. Enable the module

Next, enable your NGINX to load the PageSpeed dynamic module by editing the NGINX configuration. Simply follow the installer’s suggestion:

----------------------------------------------------------------------

The PageSpeed dynamic module for nginx has been installed.
To enable this module, add the following to /etc/nginx/nginx.conf
and reload nginx:

    load_module modules/ngx_pagespeed.so;

Please refer to the module documentation for further details:
https://developers.google.com/speed/pagespeed/module/configuration

----------------------------------------------------------------------

3.1. Configure Pagespeed cache backend

PageSpeed module needs to store its optimized resources somewhere. This is called the cache backend.

Typically, file-based cache backend is enough, provided that you have SSD. Put the following line within http { ... } section of nginx.conf for file-based cache:

pagespeed FileCachePath /var/cache/pagespeed; 

3.2. Enable Pagespeed for all websites or individual ones

Finally, enable PageSpeed globally or for specific website with pagespeed on; inside http { ... } or server { ... }, respectively.
Inside each server {} block, add locations as given below. These are required by the module.

Your complete nginx.conf will look like this:

# ... other directives ...   

load_module modules/ngx_pagespeed.so;

http {

    pagespeed FileCachePath /var/cache/pagespeed; 
    pagespeed SslCertDirectory /etc/pki/tls/certs;
    pagespeed SslCertFile /etc/pki/tls/cert.pem;

    # Enables pagespeed for each website:
    pagespeed on; 

    # ... other directives ...

    server {

        # ... other directives ...

        # Ensure requests for pagespeed optimized resources go to the pagespeed handler
        # and no extraneous headers get set.
        location ~ "\.pagespeed\.([a-z]\.)?[a-z]{2}\.[^.]{10}\.[^.]+" {
            add_header "" "";
        }
        location ~ "^/pagespeed_static/" { }
        location ~ "^/ngx_pagespeed_beacon$" { }             
    }
}

After applying the PageSpeed configuration, be sure to reload NGINX service if it is currently running:

systemctl reload nginx

It usually takes a couple of page requests before the optimizations are noticeable. To confirm if the module is functioning well, load a page a few times, then view its HTML source.
Search for .pagespeed URLs of static assets. If they are present in a page’s HTML, it means PageSpeed successfully optimized those assets and replaced their links to the URLs of optimized versions:

PageSpeed optimized image
PageSpeed optimized image

Brotli support

As it stands, the PageSpeed module does not support Brotli compression internally. That is, you can still use it along with Brotli NGINX module, but you will have to disable internal PageSpeed compression via:

pagespeed HttpCacheCompressionLevel 0;

SELinux compatibility

The SELinux module dependency package will be automatically installed for you. So no worries on that side.

Tip: if you have SELinux enabled, you may want to check our post about SELinux configuration for nginx.

Caveats

We have mentioned some techniques that PageSpeed module uses in order to optimize the performance of your pages. But some things have to be taken into account in how you use ngx_pagespeed.

CPU load

PageSpeed module does its optimizations “on the fly”. Which means it will, sure enough, increase your CPU load. Even when every static asset is already optimized, ngx_pagespeed will still have to parse and analyze HTML of your pages in order to see if there are new assets that appeared for optimization.

You may reduce the CPU load by configuring Downstream Caching, however, this has “side effects” of its own:

you may be willing to give up the benefit of the beaconing-dependent filters in exchange for never intentionally bypassing the cache

I/O impact with LoadFromFile

It is important to note the in order to extend the cache lifetime of static assets, PageSpeed does stat checks for each static file it optimized on a given page, on every page request (see issue). That may have a negative performance impact if your disk performance isn’t optimal.

Logging is too verbose

If you examine error.log of NGINX, you may find a few errors related to the PageSpeed module. Often times, they are a result of too verbose/incorrect logging, and are not an actual issue:

[ngx_pagespeed 1.13.35.2-0] Failed to read cache clean timestamp
/var/cache/pagespeed/!clean!time!. Doing an extra cache clean to be safe.

See the upstream issue: PageSpeed always emits the error when creating !clean!time, despite creation being successfull.

Supported NGINX versions: NGINX stable/mainline from either official nginx.org or GetPageSpeed repositories.

Alternatives?

You can optimize your website’s client-side performance without ngx_pagespeed if you put some effort into it.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.