What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Need a server to try this on? Antihost offers Linux VPS plans with NVMe storage, full root access and a 14-day free trial.
For a new Nginx deployment, install the maintained nginx-module-pagespeed package from the signed We-Amp repository. It is prebuilt, so you normally do not need to compile Nginx or the PageSpeed Optimization Library (PSOL). After loading the module, add the pagespeed directives, test the configuration, reload Nginx, and verify the X-Page-Speed response header.
Compile a dynamic module only when your distribution is outside the package matrix or you run a custom Nginx build. A source-built module must match the exact Nginx source version and must be rebuilt after every Nginx upgrade.
What ngx_pagespeed is today
ngx_pagespeed is the Nginx module that applies PageSpeed optimization filters to responses and related assets. The original open-source repository is archived and is no longer developed. The maintained continuation is mod_pagespeed 2.1; it preserves the pagespeed directives and filter names used by existing Nginx configurations, which makes migration possible without rewriting those directives.
The distinction matters when choosing installation instructions. The maintained module receives current development, while the legacy Google open-source code has had no security patches since 2020 and does not contain current features. Use that legacy code only when you must preserve parity with an existing deployment. It is not the appropriate starting point for a new production server.
#1 Best Overall
The maintained package is the normal route because it avoids building PSOL and avoids rebuilding a module for every Nginx upgrade. The maintainer specifically notes that the prebuilt package means there is rarely a reason to compile.
Choose the installation route
| Route | Use it when | Upgrade requirement |
|---|---|---|
Signed nginx-module-pagespeed package |
Your host is one of the supported distributions and you use its stock Nginx build | The package supplies a module matched to the distribution Nginx build, so routine Nginx upgrades do not require a local module compilation |
| Source-built dynamic module | You run a custom Nginx binary or a distribution outside the signed-package support list | Build against the exact Nginx source version you run; rebuild whenever that version changes |
Package compatibility is tied to the Nginx binary supplied by the distribution. A module installed for the stock binary can fail to load with an Nginx binary obtained from another repository, even when both packages report the same nominal Nginx version.
Check whether your host is supported
The current signed-package matrix covers these combinations:
| Distribution family | Releases | Architectures |
|---|---|---|
| Ubuntu | 22.04 and 24.04 | amd64 and arm64 |
| Debian | 11, 12 and 13 | amd64 and arm64 |
| EL9 distributions, including AlmaLinux, Rocky Linux and RHEL | EL9 | x86_64 and aarch64 |
| EL10 | EL10 | x86_64 |
If your release or architecture is not in this matrix, plan on the source-build procedure instead. Before changing a running server, record how Nginx was installed and which binary systemd starts. The signed module is intended for the distribution’s stock build, not an unrelated third-party binary.
Prepare the host before installation
Plan the change as an Nginx configuration update, not as a replacement of the web server. The package adds a dynamic module; it does not replace your Nginx server package or discard your virtual hosts. Make a copy of the active configuration and note which include files are loaded so you can identify an automatically installed module line and avoid adding a duplicate.
You need administrative privileges for the repository installer, package installation, copying a source-built shared object, and reloading the service. The package path requires a supported APT- or DNF-based host and a stock distribution Nginx build. A source build additionally requires the compiler and development dependencies used to build Nginx modules, the maintained module source, and the exact Nginx source tree corresponding to the binary in production.
Choose the cache location before enabling PageSpeed. The directory named by pagespeed FileCachePath must exist and be writable by the account running Nginx workers. A path that is present but owned or permissioned for another user can leave the module loaded while preventing it from storing optimized results. Correct the path ownership or permissions before testing the live configuration.
Install the signed package
1. Add the signed repository
Run the maintainer’s installer:
curl -fsSL https://packages.modpagespeed.com/install.sh | sudo shThe command adds the package source and its signing configuration. Review your distribution’s package output and confirm that the repository was accepted before proceeding.
2. Install the module package
On Debian or Ubuntu, use APT:
sudo apt install nginx-module-pagespeedOn AlmaLinux, RHEL and other supported EL-family systems, use DNF:
sudo dnf install nginx-module-pagespeedInstalling the module does not replace your Nginx server package. It adds the dynamic module file and the distribution’s normal module-loading integration.
Recommended Free Tools
3. Confirm that Nginx will load the module
Distribution packages commonly install this directive automatically:
load_module modules/ngx_pagespeed_module.so;It must be in Nginx’s main context: place it at the top level of nginx.conf, outside both http {} and server {}. Package layouts that provide modules-enabled usually enable the line through an included file. If your Nginx came from a third-party repository and does not have that layout, add one top-level line manually.
Do not add a second copy. Duplicate load directives can make configuration testing fail, and an incorrect module path produces a dynamic-loader error. The module is compiled for the distribution’s stock Nginx build; if you use a different Nginx binary, stop here and use the source-build path.
4. Add the minimal PageSpeed configuration
Put these directives in the http {} context, or in a file included from it:
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →pagespeed on;
pagespeed FileCachePath /var/cache/ngx_pagespeed;
pagespeed RewriteLevel CoreFilters;
location ~ "\.pagespeed\.([a-z]\.)?[a-z]{2}\.[^.]{10}\.[^.]+" { add_header "" ""; }
location ~ "^/pagespeed_static/" { }
location ~ "^/ngx_pagespeed_beacon$" { }CoreFilters is the maintainer’s safe starting level. It enables the core filter set without asking you to choose individual filters. The cache directory must exist and be writable by the account that runs Nginx; otherwise optimization work can fail when the worker tries to write cached data.
The three location blocks belong with the PageSpeed configuration. Keep their syntax intact, including the escaped dots and the empty add_header values. If you already have location rules, check their order so a broader rule does not prevent these PageSpeed locations from being selected. Keep the PageSpeed directives in an active HTTP or server configuration; placing them in an unrelated include that is never loaded has the same effect as omitting them.
5. Test and reload safely
- Run the configuration test:
sudo nginx -t - Only after the test reports a valid configuration, reload the service:
sudo systemctl reload nginx - Make the request used for verification against a URL served by this Nginx instance.
A reload applies the module and directives without stopping the existing worker processes. If nginx -t fails, do not reload; fix the reported line first. A successful package installation does not prove that the active service loaded the module, because the running Nginx may use a different configuration tree or binary.
Verify that PageSpeed is active
Check the response headers:
curl -sI https://yoursite/ | grep -i x-page-speedReplace the host in the command with the site handled by this Nginx server. An X-Page-Speed header containing a version string indicates that the worker is optimizing the response. Header matching is case-insensitive in the command, so it will find the conventional capitalization used by the module.
Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Clear out junk files and repair common Windows errors3Scan for outdated or missing drivers - takes under a minuteIf no matching header appears, first confirm that the request reached the intended virtual host. Then check that the module-loading line is present in the main context and that pagespeed on; is active in the relevant HTTP or server configuration. Confirm that the cache path is writable, reload after any correction, and repeat the header check. A successful package installation alone does not enable PageSpeed processing; both the dynamic module and the directive must be active.
Build ngx_pagespeed as a dynamic module
Use this route for a custom Nginx build or a host outside the signed-package matrix. Install the compiler and the development dependencies required by your operating system, obtain the maintained module source, and use the Nginx source tree for the exact version of the binary you run.
1. Configure against the matching Nginx source
The documented pattern below uses an Nginx 1.26.3 source directory and a neighboring maintained module directory:
cd ../nginx-1.26.3
./configure --add-dynamic-module=../ngx_pagespeed --with-compat
make modulesThe command must be run from the Nginx source tree. The --with-compat option builds a dynamic module with Nginx’s compatibility setting; it does not make a module universally interchangeable between unrelated Nginx versions. Keep the source version, configure arguments, and resulting module together in your deployment records so the build can be reproduced.
Free tools Windows power users keep installed
One-click scans. No signup required.
Rank #3
2. Install the resulting module
sudo cp objs/ngx_pagespeed_module.so /usr/lib/nginx/modules/Load it from the main Nginx context:
load_module modules/ngx_pagespeed_module.so;Use one load directive only. If an old package or include file already loads the module, remove or disable that duplicate before testing. The path in the loader must resolve to the shared object you copied; a successful compile does not help if Nginx is looking in another modules directory.
3. Apply the same PageSpeed configuration
Add pagespeed on;, a writable pagespeed FileCachePath, pagespeed RewriteLevel CoreFilters;, and the three PageSpeed location blocks shown in the package procedure. The configuration syntax is the same because the maintained continuation preserves the existing directive and filter names.
4. Test, reload and verify
- Run
sudo nginx -t. - Reload with
sudo systemctl reload nginxafter the test succeeds. - Check the response with
curl -sI https://yoursite/ | grep -i x-page-speedand look for the version-bearing header.
Dynamic modules are version-specific. Rebuild and reinstall this file whenever the Nginx version changes, then repeat the configuration test and reload. Keeping an old module beside a newer Nginx binary is a common cause of load failures. The --with-compat flag does not remove this maintenance requirement.
Migrate an existing open-source ngx_pagespeed installation
The maintained migration path is a package swap rather than a configuration rewrite:
- Remove the old open-source module from the existing installation.
- Install the signed
nginx-module-pagespeedpackage using the repository and package-manager steps above. - Retain the existing
pagespeeddirectives where they are compatible with the maintained continuation. - Inspect all Nginx includes and ensure exactly one line loads
/usr/lib/nginx/modules/ngx_pagespeed_module.so. - Run
sudo nginx -t, reload Nginx, and verifyX-Page-Speed.
Keeping the directives is possible because mod_pagespeed 2.1 maintains the directive and filter names used by the older Nginx configuration. The migration does not justify continuing to compile the archived legacy code, which lacks security patches since 2020. Test one representative response after migration before treating the change as complete.
Troubleshoot the common failure modes
| Symptom | Likely cause | Correction |
|---|---|---|
unknown directive "pagespeed" during nginx -t |
The dynamic module was not loaded before the configuration was parsed | Add or repair the top-level load_module modules/ngx_pagespeed_module.so; line, then test again |
| Nginx reports that it cannot load the shared object | The module path is wrong, the file is missing, or the module was built for a different Nginx binary | Confirm the installed file and use the stock distribution Nginx with the package; otherwise rebuild against the exact binary’s source |
nginx -t reports a duplicate module |
Both an automatically included file and a manual line load the module | Leave exactly one load directive in the main context |
The site responds but has no X-Page-Speed header |
pagespeed on; is absent from the active context, or the request is handled by a server block without the module configuration |
Check the active include and server configuration, confirm the module is loaded, reload after a successful test, and repeat the header check |
| PageSpeed cannot write its cache | The configured FileCachePath is not writable by the Nginx worker account |
Choose a writable cache path and correct its ownership or permissions before reloading |
| The module stops loading after an Nginx upgrade | A source-built dynamic module was compiled for the previous Nginx version | Rebuild the module against the new exact Nginx source and reinstall the resulting shared object |
Operational choices after installation
Package-managed hosts
Keep Nginx and the PageSpeed module on the same distribution packaging track. The signed package path is designed to remove the recurring PSOL and module build steps, but its compatibility assumption remains the stock distribution Nginx build. If you replace that binary with one from another repository, reassess compatibility before restarting or reloading.
When applying normal package updates, repeat the configuration test and verify a response header after the service reload. This catches a changed include path, an unintended binary replacement, or a permissions change on the cache directory before those issues become difficult to diagnose.
Custom-build hosts
Record the Nginx source version used for each module build. Treat the ngx_pagespeed_module.so file as part of that particular Nginx build, not as a permanent system-wide plug-in. Every Nginx version change requires a matching rebuild and a fresh nginx -t check.
Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchPC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Performance expectations
No dated benchmark establishes a universal speed improvement for this installation. The defensible expectation is functional: when the module is loaded, PageSpeed is enabled, and the cache is writable, the worker can apply its configured optimization filters and identify optimized responses with the X-Page-Speed header. Results depend on the site’s responses and the selected filter level, so measure your own traffic rather than relying on an invented percentage.
Support and commercial options
The module itself is free software. We-Amp also offers optional support and hardened, attested builds for operators who need a maintained commercial channel. Those services are separate from the installation commands above; evaluate their current scope and terms directly if you need support commitments or attestation.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Frequently asked questions
Do I have to compile Nginx or PSOL?
No, not on a supported distribution using its stock Nginx package. The signed nginx-module-pagespeed package is prebuilt and avoids both a local PSOL build and repeated module compilation. Compile a dynamic module only for an unsupported host or a custom Nginx binary.
Rank #4
Is the original ngx_pagespeed repository still maintained?
No. The original open-source repository is archived. The maintained continuation is mod_pagespeed 2.1, which retains the established directive and filter names.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Clear out junk files and repair common Windows errorsFree Scan →Which operating systems can use the signed package?
Supported combinations are Ubuntu 22.04 and 24.04 on amd64 or arm64; Debian 11, 12 and 13 on amd64 or arm64; EL9 distributions such as AlmaLinux, Rocky Linux and RHEL on x86_64 or aarch64; and EL10 on x86_64. Other combinations generally require a source build.
Where does load_module belong?
It belongs in Nginx’s main context, outside http {} and server {}. Put pagespeed directives in the active HTTP or server configuration. Ensure only one loader line is present.
How do I know PageSpeed is working?
Request a URL from the intended Nginx virtual host and inspect the headers with curl -sI https://yoursite/ | grep -i x-page-speed. A version-bearing X-Page-Speed value indicates that the worker is optimizing. Its absence means you should check the loaded module, active directive, request routing, and cache permissions.
What happens when I upgrade Nginx after a source build?
Rebuild the dynamic module against the exact new Nginx source version, copy the resulting shared object into the modules directory, test the configuration, reload, and verify the header again. An old module is not a permanent plug-in for a newer Nginx binary.
Can I keep my existing PageSpeed configuration during migration?
Usually yes. The maintained continuation preserves the existing pagespeed directives and filter names. Remove the old module, install the signed package, ensure exactly one loader line points to the maintained module, then test and verify before considering the migration finished.
Should I use the legacy Google module for a new server?
No. The legacy code has had no security patches since 2020 and lacks current features. Reserve it for a narrowly defined parity requirement in an existing deployment, not for a new production installation.
Recommended decision
Use the signed nginx-module-pagespeed package on a supported distribution with its stock Nginx build. Add the single main-context loader, start with RewriteLevel CoreFilters, provide a writable cache directory, and verify the header after a tested reload. Choose a source build only when package coverage or binary compatibility requires it, and rebuild that module for every Nginx version change.
Frequently Asked Questions
What is the easiest way to install ngx_pagespeed on Nginx?
Use the signed We-Amp repository and install nginx-module-pagespeed with APT or DNF on a supported distribution. The package is prebuilt, so compiling Nginx is normally unnecessary.
Free tools Windows power users keep installed
One-click scans. No signup required.
Why is pagespeed an unknown directive?
Nginx parsed the configuration before loading the dynamic module. Add exactly one top-level load_module modules/ngx_pagespeed_module.so; line, then run nginx -t again.
Does a source-built module survive an Nginx upgrade?
No. Rebuild and reinstall the module against the exact new Nginx source version after every Nginx version change.
What does the X-Page-Speed header prove?
A version-bearing header shows that the loaded worker is applying PageSpeed optimization to the response. If it is absent, check module loading, the active pagespeed on; directive, request routing, and cache permissions.
The Bottom Line
For supported hosts, install the signed prebuilt nginx-module-pagespeed package, load it once in Nginx’s main context, enable CoreFilters with a writable cache, and verify X-Page-Speed after nginx -t and a reload. Use a matching source build only for custom or unsupported Nginx installations, and rebuild it after every Nginx upgrade.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Scan for outdated or missing drivers - takes under a minute3Clear out junk files and repair common Windows errorsQuick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
