NGINX PageSpeed ARM64: Magento Optimization on Rocky Linux 9

📅 Updated: August 6, 2026 (Originally published: January 28, 2026)

NGINX PageSpeed ARM64 matters when Magento can render storefront HTML quickly from Varnish and still send needlessly large images, verbose CSS, and unoptimized JavaScript to the browser. Redis solves a different problem: it accelerates Magento sessions and application cache data. Neither service rewrites the final storefront assets that determine how much the customer downloads.

GetPageSpeed’s NGINX PageSpeed ARM64 build closes that last-mile gap. The new beta11 package uses a modernized C++20 PageSpeed engine as a dynamic NGINX module for both x86_64 and aarch64 on Enterprise Linux 9. It can optimize the HTML, CSS, JavaScript, and images Magento emits without modifying theme source files.

This is a technical preview in the GetPageSpeed testing repository. It is the practical route for testing PageSpeed on Rocky Linux 9, AlmaLinux 9, RHEL 9, AWS Graviton, Ampere, and other ARM64 servers with a current NGINX package.

The NGINX PageSpeed ARM64 gap

ARM users have been asking for PageSpeed support for years. An upstream request for ARM support dates to 2016, while a 2023 aarch64 request still described the available ARM build as outdated. Apache officially retired the PageSpeed incubator project in March 2023.

There were community ARM experiments, so it would be inaccurate to claim nobody had ever compiled PageSpeed for ARM. The real supply gap was a current, packaged, supported build that follows a modern NGINX release and installs through a repository.

That is what GetPageSpeed technology now provides:

• EL9 packages for aarch64 and x86_64
• A C++20 libpagespeed SDK built natively for each architecture
• A dynamic module compatible with GetPageSpeed NGINX 1.30.4
• Native same-origin HTTP resource fetching
• A deterministic LoadFromFile path for HTTPS storefront assets
• Automated unit, stable-NGINX, mainline-NGINX, package-install, liveness, and graceful-shutdown tests

The result is not an abandoned binary copied into a repository. It is a maintained packaging and verification pipeline around revived PageSpeed technology.

How PageSpeed fits into a Magento stack

A fast Magento deployment uses several cache layers. They are complementary, not interchangeable.

Layer	Recommended job
Varnish	Full-page cache in front of Magento
Redis	Magento sessions, default cache, and application cache data
NGINX PageSpeed	Rewrite the final HTML and static assets sent to browsers
Browser and CDN caches	Reuse fingerprinted optimized resources near the visitor

Adobe’s current Commerce software recommendations recommend Varnish for full-page caching and Redis for sessions and the default cache. Keep that architecture.

PageSpeed beta11 does not use Redis or Memcached as its rewrite cache. It uses FileCachePath. If Magento already uses Redis or Memcached, leave that application cache configuration separate. Point PageSpeed at a dedicated local directory and monitor its disk usage.

The request path looks like this:

1. Magento or Varnish produces the storefront HTML.
2. NGINX passes the response through PageSpeed.
3. PageSpeed parses the HTML and finds eligible CSS, JavaScript, and image URLs.
4. On HTTPS Magento sites, LoadFromFile reads those public assets directly from Magento’s pub directory.
5. PageSpeed writes optimized variants to its file cache and replaces the original URLs in the response.
6. Browsers receive fingerprinted resources with cache-friendly URLs.

Because the optimization happens inside NGINX, no remote optimization proxy sits between your customer and the store.

Install the PageSpeed beta on Rocky Linux 9

The beta11 package is currently available from the opt-in EL9 testing channel. Test it on staging before enabling it for production traffic.

First install the GetPageSpeed repository package:

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

Then install NGINX and PageSpeed from the testing channel:

sudo dnf install -y --enablerepo=getpagespeed-extras-testing \
    nginx nginx-module-pagespeed

Confirm that DNF installed the expected architecture and beta:

rpm -q nginx nginx-module-pagespeed
uname -m

On ARM64, uname -m must print aarch64. The PageSpeed package name should contain 1.30.4+2.1.0~beta11.

The testing repository requires an active GetPageSpeed repository subscription. The package is not yet available for Debian or Ubuntu. Do not substitute old PSOL binaries from abandoned PageSpeed guides because those builds do not represent the module tested here.

Configure PageSpeed for an HTTPS Magento storefront

Load the module once at the top level of /etc/nginx/nginx.conf, before the events and http blocks:

load_module modules/ngx_pagespeed.so;

Add the following directives to the existing HTTPS server block for the Magento store. Replace the domain and Magento path with the real values for your deployment.

pagespeed on;
pagespeed FileCachePath /var/cache/pagespeed;
pagespeed LoadFromFile "https://shop.example.com/" "/var/www/magento/pub/";
pagespeed RewriteLevel PassThrough;
pagespeed EnableFilters rewrite_images,rewrite_css,rewrite_javascript,collapse_whitespace,remove_comments,extend_cache;

location ~ "\.pagespeed\.([a-z]\.)?[a-z]{2}\.[^.]{10}\.[^.]+" {
}

location ~ "^/pagespeed_static/" {
}

location = /ngx_pagespeed_beacon {
}

Why use LoadFromFile? Beta11 can fetch same-origin resources through NGINX over plain HTTP, but its native fetcher does not yet support HTTPS. Magento storefronts should be HTTPS, so this mapping gives PageSpeed a direct, fast, deterministic route from the public URL prefix to Magento’s pub directory.

The URL prefix must match the canonical storefront origin exactly, including `https://` and the hostname. The disk path must end at the public web root, not the Magento project root.

The selected filters form a conservative starting set:

Directive or filter	Purpose
FileCachePath	Stores rewritten metadata and resources on local disk
LoadFromFile	Maps public HTTPS asset URLs to Magento’s local pub tree
PassThrough	Starts with no implicit optimization bundle
rewrite_images	Recompresses eligible images and rewrites their URLs
rewrite_css	Minifies and rewrites CSS resources
rewrite_javascript	Minifies eligible JavaScript resources
collapse_whitespace	Removes unnecessary HTML whitespace
remove_comments	Removes nonessential HTML comments
extend_cache	Produces fingerprinted, cache-friendly resource URLs

Starting from PassThrough makes the rollout auditable. Add more filters only after visual regression testing checkout, account, search, layered navigation, and third-party payment flows.

Test before reloading NGINX

Validate the complete configuration:

sudo nginx -t

If the syntax test succeeds, reload NGINX gracefully:

sudo nginx -s reload

Request a public product or category page and inspect the PageSpeed header:

curl -sS -D- -o /tmp/storefront.html https://shop.example.com/ \
    | grep -i '^x-page-speed:'

The beta11 package returns the fixed source commit in its build identifier:

X-Page-Speed: 2.1.0.0-388b834

Now inspect the saved HTML:

grep -oE '[^" ]+\.pagespeed\.[a-z]{2}\.[^" ]+' /tmp/storefront.html | head

Rewritten URLs contain markers such as:

• .pagespeed.cf. for rewritten CSS
• .pagespeed.jm. for rewritten JavaScript
• .pagespeed.ic. for rewritten images

No header usually means the response was not HTML, PageSpeed was disabled in that context, or another location handled the request. A header without rewritten asset URLs usually points to an incorrect LoadFromFile mapping, an ineligible resource, or a filter that has not completed its first rewrite yet.

Verified ARM64 behavior

The beta11 configuration was exercised on ARM64 with a Magento-shaped fixture containing versioned theme CSS, theme JavaScript, and a catalog JPEG.

The verification produced all three rewritten resource classes and served every generated URL with HTTP 200. The JPEG changed from 241,260 bytes to 98,051 bytes, a 59 percent reduction for that fixture. This is a functional result, not a promise that every Magento image will shrink by the same amount.

The same run verified:

• nginx -t passed with the dynamic module and article directives
• The response included X-Page-Speed: 2.1.0.0-388b834
• CSS, JavaScript, and image URLs were rewritten
• The generated CSS, JavaScript, and image resources returned HTTP 200
• The PageSpeed file cache populated
• A graceful NGINX quit ended the worker with code 0 and no SIGSEGV

The graceful-shutdown check matters. Testing this article exposed a null-fetcher crash in beta10 that its original liveness smoke did not detect. Beta11 fixes the cleanup path and adds a permanent shutdown regression test to the package pipeline.

Performance and capacity planning

PageSpeed trades server CPU, memory, and disk I/O for smaller and more cacheable browser resources. The first request for a resource is the expensive one. Later requests can reuse the optimized file-cache entry.

Use these rollout practices:

1. Enable the conservative filter set on staging.
2. Warm representative catalog, category, CMS, and checkout pages.
3. Measure CPU, disk use, response time, and Core Web Vitals before and after.
4. Roll out to a small share of production traffic.
5. Keep enough free disk space for both Magento static content and the PageSpeed cache.
6. Exclude resources that break under minification instead of enabling a large filter bundle blindly.

PageSpeed cannot repair slow PHP, database queries, cache misses, or an undersized Redis instance. Fix time to first byte with Magento profiling, Varnish, Redis, PHP-FPM tuning, and database work. Use PageSpeed for the transfer and rendering work that remains after the HTML exists.

Security and operational guidance

Treat PageSpeed as executable infrastructure, not a theme plugin.

• Install only the matching GetPageSpeed NGINX and module packages. Dynamic module ABI mismatches can prevent NGINX from starting.
• Keep the file cache owned by the NGINX worker account and do not make it world-writable.
• Map only the Magento pub directory with LoadFromFile. Never expose the Magento project root, app/etc/env.php, var, or generated private data.
• Run nginx -t before every reload.
• Keep checkout and payment journeys in the visual regression suite.
• Clear or rotate the PageSpeed file cache during controlled maintenance when changing major filter behavior.
• Remember that this package is in the testing channel. Pin and promote it through your own staging process.

Troubleshooting

unknown directive "pagespeed"

The dynamic module was not loaded. Confirm that this line is at the top level of nginx.conf:

load_module modules/ngx_pagespeed.so;

Also confirm ngx_pagespeed.so exists in /usr/lib64/nginx/modules and that NGINX and the module came from the same repository build.

NGINX reports a binary compatibility error

Update NGINX and PageSpeed together from the testing channel. The module package depends on the matching GetPageSpeed NGINX release.

The header appears but Magento assets are unchanged

Check the error log first:

sudo grep -i pagespeed /var/log/nginx/error.log | tail -50

For HTTPS, verify that LoadFromFile uses the canonical public origin and the real Magento pub path. Confirm that the NGINX worker can read the mapped files and write to /var/cache/pagespeed.

Redis or Memcached usage does not change

That is expected. PageSpeed beta11 does not store its rewrite cache in Redis or Memcached. Those services remain in the Magento application layer. Inspect /var/cache/pagespeed to confirm PageSpeed activity.

A theme or payment extension breaks

Return to the six-filter baseline shown above. Disable rewrite_javascript first for JavaScript regressions, then test CSS and image filters independently. Exclude the specific resource once identified. Do not disable Magento’s security headers or weaken Content Security Policy to hide a rewrite problem.

Frequently asked questions

Does NGINX PageSpeed replace Redis for Magento?

No. Redis stores Magento sessions and application cache data. PageSpeed rewrites the finished HTML and static assets at the NGINX layer. A serious Magento deployment can use both.

Does PageSpeed beta11 support AWS Graviton?

Yes. Graviton uses the aarch64 architecture supported by the EL9 testing package. Verify that the operating system reports aarch64 and use a supported Enterprise Linux 9 distribution.

Is this the original Google binary?

No. GetPageSpeed builds a modernized C++20 libpagespeed SDK and NGINX dynamic module for current packaging targets. The original Apache incubator project is retired.

Can I install this package on Rocky Linux 10?

Not yet. Beta11 currently ships an EL9 SDK and testing RPM. This article replaces an older guide that incorrectly claimed EL10 availability.

Is Debian or Ubuntu supported?

Not for this beta. The current technical preview is packaged for Enterprise Linux 9 on x86_64 and aarch64.

Conclusion

A fast Magento PageSpeed configuration only stays correct until the next theme, module, or NGINX change. Continuous checks are how you catch asset and configuration regressions before customers do. GetPageSpeed Amplify runs scheduled gixy scans across every host and ties findings to live NGINX runtime metrics. Drop-in compatible with the deprecated nginx-amplify-agent (EOL January 2026).

GetPageSpeed NGINX PageSpeed ARM64 beta11 brings a current, packaged PageSpeed stack to ARM64 and x86_64 Enterprise Linux 9 servers. For Magento, it occupies a precise place: Varnish caches pages, Redis caches application data, and PageSpeed optimizes the bytes delivered by NGINX.

Start with the verified six-filter baseline, use LoadFromFile for HTTPS assets, and prove checkout behavior before expanding the filter set. Review the PageSpeed module documentation and activate the GetPageSpeed repository when you are ready to test it on staging.