As the average size of web pages continues to grow, it is increasingly important to optimize all aspects of design, development, and delivery of your website in order to ensure a good experience for your users, regardless of what device they are using. It is well documented that page load time impacts user experience and revenue.
Google PageSpeed is a suite of tools for measuring and optimizing the performance of your website, and has been available for several years as a third‑party module you can compile into NGINX Open Source. With the introduction of dynamic modules in NGINX Plus R11, NGINX Plus users can now take advantage of PageSpeed as well.
When you load PageSpeed as a dynamic module into NGINX Plus, it automatically rewrites and optimizes resources on your website. In this blog post we explain how to build and configure the dynamic module. (Keep in mind that as a third‑party module, PageSpeed is not covered by your NGINX Plus support agreement.)
Building and Loading PageSpeed as a Dynamic Module for NGINX Plus
The following instructions are based on Google’s manual install instructions, and adapted for binary compatibility with NGINX Plus. (You can use Google’s instructions unchanged to build a dynamic module that works with NGINX Open Source.)
Step 0: Preparing the Build Environment
We strongly recommend that you compile dynamic modules on a separate system, which we refer to here as the “build environment”. Doing so minimizes the risk and complexity of the system where you plan to run NGINX Plus with the PageSpeed module (we refer to this as the “production environment”). The build environment must have the same operating system and version as the production environment; in addition, the following components must be installed:
- UnZip utility
- Compiler and make utility
- Perl‑compatible regular expressions library (development files)
- Zlib compression libraries (development files)
To ensure your build environment has these prerequisites installed, run the following command.
- For Ubuntu/Debian:
- For CentOS/RHEL/Oracle Linux:
Step 1: Obtaining NGINX Open Source
- Working in the production environment, run the following command to identify the NGINX Open Source version that corresponds to the running NGINX Plus release. It’s highlighted in orange in this output: NGINX 1.11.5, which corresponds to NGINX Plus R11.
- Working in the build environment, download the sources for the appropriate NGINX Open Source version.
Step 2: Downloading and Preparing the PageSpeed Sources
Perform these steps in the build environment.
- Look up the latest version number of the PageSpeed module in the release notes, or by running this command.
- The PageSpeed version number is used multiple times in the build commands, so set it as an environment variable,
NPS_VERSION. Include only the numeric part of the version string, not the ‑stable or ‑beta suffix. - Download and extract the sources as follows. Note that these commands are expected to be run sequentially, like a script.
Step 3: Compiling the PageSpeed Dynamic Module
- Working in the build environment, compile the PageSpeed dynamic module by first running the NGINX
configurescript with the--with-compatargument to make the dynamic module binary‑compatible with NGINX Plus. Then runmakemodulesto compile just the module. - The build process produces the dynamic module as objs/ngx_pagespeed.so. Copy the .so file from the build environment to the modules directory, /etc/nginx/modules, in the production environment. We recommend (and the following step assumes) that as you copy the file over you rename it to include the NGINX Open Source version number, for example ngx_pagespeed_1.11.5.so.
- Working in the production environment, create a symbolic link between the version‑numbered filename and the generic (original) filename.
Step 4: Loading the PageSpeed Dynamic Module
Perform these steps in the production environment.
- Include the
load_moduledirective to load PageSpeed as a dynamic module. The directive must appear in the top‑level (“main”) context of the nginx.conf configuration file (that is, not in thehttporstreamcontexts). - PageSpeed itself is configured in the
httpcontext so put these directives in a new configuration file called pagespeed.conf in the /etc/nginx/conf.d directory. PageSpeed is activated for the website specified in theproxy_passdirective, here http://www.example.com. - Reload NGINX Plus to load the PageSpeed module into the running instance.
Testing the NGINX Plus PageSpeed Module with PageSpeed Insights
PageSpeed Insights is a separate tool provided by Google for measuring the level of optimization applied to a web page for both mobile and desktop devices. It provides a score for both devices with suggestions for how to make the page load faster. It is a useful tool for measuring your site and for demonstrating the effectiveness of the PageSpeed module.
You can use PageSpeed Insights to compare your site score and suggestions for optimization with and without PageSpeed enabled. Swap between the pagespeed on; and pagespeed off; directives to measure the effectiveness of the PageSpeed module on your site.
PageSpeed applies its optimizations without any further configuration or tuning. However, if you want to have more control over which optimizations are performed on your site, refer to the PageSpeed documentation.
Try out PageSpeed with NGINX Plus for yourself – start your free 30-day trial today or contact us to discuss your use cases.
About the Author

Related Blog Posts
Secure Your API Gateway with NGINX App Protect WAF
As monoliths move to microservices, applications are developed faster than ever. Speed is necessary to stay competitive and APIs sit at the front of these rapid modernization efforts. But the popularity of APIs for application modernization has significant implications for app security.
How Do I Choose? API Gateway vs. Ingress Controller vs. Service Mesh
When you need an API gateway in Kubernetes, how do you choose among API gateway vs. Ingress controller vs. service mesh? We guide you through the decision, with sample scenarios for north-south and east-west API traffic, plus use cases where an API gateway is the right tool.
Deploying NGINX as an API Gateway, Part 2: Protecting Backend Services
In the second post in our API gateway series, Liam shows you how to batten down the hatches on your API services. You can use rate limiting, access restrictions, request size limits, and request body validation to frustrate illegitimate or overly burdensome requests.
New Joomla Exploit CVE-2015-8562
Read about the new zero day exploit in Joomla and see the NGINX configuration for how to apply a fix in NGINX or NGINX Plus.
Why Do I See “Welcome to nginx!” on My Favorite Website?
The ‘Welcome to NGINX!’ page is presented when NGINX web server software is installed on a computer but has not finished configuring
