yum upgrades for production use, this is the repository for you.
Active subscription is required.
📅 Updated: April 22, 2026 (Originally published: March 6, 2020)
Update, 2026-04-23: When this article was first published in 2020, it recommended Intel’s and Cloudflare’s zlib forks. Both have since been shelved upstream: Intel archived its fork on 2024-03-01, and Cloudflare now steers users toward the Rust-based zlib-rs. Today the right drop-in is zlib-ng, and we ship it for every supported distro. If you installed the old
intel-zliborcloudflare-zlibpackage in the past, the nextyum updatetransparently replaces it withzlib-ng. No further action needed.
Why faster zlib matters
zlib is the quiet workhorse behind roughly everything that touches compressed data on a Linux server. Your web server negotiates gzip with browsers through it. Your database stores backups with it. Your log rotation squeezes yesterday’s logs through it. Every build of curl, rpm, git, OpenSSH, and NGINX on your box links against libz.so.1 by default.
The stock zlib that ships with every distro is conservative by design: it builds portably, favors compatibility with very old CPUs, and has barely changed in over a decade. Modern hardware can do much better. The maintained successor, zlib-ng, exploits SIMD instructions (SSE2/SSSE3/SSE4/AVX2/AVX-512 on x86_64, ARMv8 CRC plus NEON on aarch64) and gives you a measurable win on every code path that touches compression, without disturbing the stock zlib that’s already on disk.
Because zlib is baked into so many programs at link time, you don’t have to rebuild anything to benefit. Switch the library underneath, restart the services, and every one of them starts using zlib-ng on its next compression call. That includes services you don’t manage directly: cron jobs doing gzip on logs, backup agents pushing tarballs to object storage, package tools building and extracting .rpm and .gz files.
Recommended: install zlib-ng
Two commands from any GetPageSpeed-supported Linux distro and you’re done:
sudo yum -y install https://extras.getpagespeed.com/release-latest.rpm
sudo yum -y install zlib-ng
(Use dnf instead of yum on newer distros. Both work.)
The zlib-ng package is available for:
- RHEL, CentOS Stream, Rocky Linux, AlmaLinux 7, 8, 9, and 10
- Amazon Linux 2 and 2023
- Fedora 42 and 43
- SLES 16
All on both x86_64 and aarch64. EL6 was dropped on purpose (EOL upstream and on our side).
How the drop-in works, and why it’s safe
zlib-ng advertises the same SONAME as stock zlib, libz.so.1, so any binary that already links against zlib will happily load it instead. What we do differently from a naive “replace the system package” approach is install into an isolated directory:
/usr/lib64/zlib-ng/libz.so.1
and drop a file into /etc/ld.so.conf.d/ that puts that directory ahead of the default library path. The dynamic linker finds ours first and loads it. The system zlib RPM is never removed, renamed, or overwritten on disk, which matters for two reasons:
- Clean revert.
yum remove zlib-ngputs you straight back on stock zlib, with no repair step and no emergency boot. - No fights with distro updates. When CentOS, Rocky, or Amazon ship a zlib security patch, it lands on disk as usual. It simply doesn’t get loaded, because ours wins the library search.
Verify it’s actually in use
After installing, restart a long-running service you care about (systemctl restart nginx) and spot-check its linkage:
ldd $(which nginx) | grep libz
# libz.so.1 => /usr/lib64/zlib-ng/libz.so.1 (0x00...)
If the path on the right is /usr/lib64/zlib-ng/libz.so.1, you’re on zlib-ng. If it still says /lib64/libz.so.1, run sudo ldconfig and restart the process.
Same trick works for anything else you want to confirm: ldd $(which mysqld) | grep libz, ldd $(which redis-server) | grep libz, and so on. A more thorough check is to inspect a running worker’s memory map:
pid=$(pgrep -f 'nginx: worker' | head -1)
grep libz /proc/$pid/maps
If you see /usr/lib64/zlib-ng/libz.so.1.3.1.zlib-ng in that output, the kernel is actually running zlib-ng code in the worker, not just reporting it at link time.
Workloads that benefit most from zlib-ng
Every compression call gets a little faster, but the curve isn’t flat. The wins are biggest where:
- Your CPU has modern SIMD: Skylake-X, Ice Lake, Sapphire Rapids, Zen 3 and newer, any Graviton, Ampere Altra, or Apple-silicon-class ARM server CPU. AVX-512 on x86_64 and the ARMv8 CRC instructions on aarch64 are where zlib-ng pulls ahead the hardest.
- You compress a lot of small payloads: HTTP responses, Redis command streams, row-level compressed columns in a database. Per-call overhead dominates on tiny inputs, and zlib-ng is tighter there.
- You decompress in hot paths: package managers installing RPMs, CI pipelines extracting tarballs, game servers loading pre-compressed assets. Decompression is where both zlib-ng and zlib-rs post the largest gains over stock zlib.
Workloads with negligible compression (no gzip, no .tar.gz, no compressed database) will see no measurable change. That’s fine. The package is harmless there and costs you roughly 180 KB of disk.
What’s next: zlib-rs
Worth knowing about, even though we don’t ship it yet. zlib-rs is a memory-safe Rust rewrite by the Trifecta Tech Foundation and ISRG Prossimo (the same ISRG behind Let’s Encrypt). Version 0.4.2 (Feb 2025) beats zlib-ng by 6 to 10 percent on decompression of small inputs, which is exactly the workload a busy web server sees all day. It also ships a C-ABI drop-in (libz-rs-sys), so in principle it can slot into the same ld.so.conf.d trick we use above.
We’ll package zlib-rs once the ecosystem settles (once libz-rs-sys stabilizes and distros pick it up). Until then, zlib-ng is the one to install. Both are roughly 3x faster than stock zlib at decompression, so you’re not leaving meaningful performance on the table by running zlib-ng today.
Historical note: Intel and Cloudflare forks
For context, since the old instructions still float around:
- Intel’s zlib fork (
jtkukunas/zlib) was archived on 2024-03-01 with the notice “Intel has ceased development and contributions to this repository.” We previously packaged it asintel-zlib. - Cloudflare’s zlib fork (
cloudflare/zlib) is deprecated. Cloudflare’s engineering team now steers users toward zlib-rs for memory safety. We previously packaged it ascloudflare-zlib.
The original 2020 recommendations looked like this:
# Historical, not recommended in 2026. Left here for reference.
sudo yum -y install intel-zlib
# or
sudo yum -y install cloudflare-zlib
If you ran either of those commands on a server years ago, you don’t have to do anything special. The new zlib-ng package declares Obsoletes: intel-zlib and Obsoletes: cloudflare-zlib in its RPM metadata, so the next yum update quietly retires the old fork and swaps in zlib-ng. The on-disk library path shifts from /usr/lib64/libz.so.1 to /usr/lib64/zlib-ng/libz.so.1, and the ld.so.conf.d entry keeps the runtime linker pointed at our copy.
Troubleshooting
ldd still shows /lib64/libz.so.1 after install. The ldconfig cache is stale. Run sudo ldconfig to rebuild it, then restart the service whose linkage you’re checking. Long-running daemons cache their dynamic-link decisions at process startup, so a bare ldconfig alone isn’t enough: the service has to be restarted (or reload, for services whose reload path re-execs).
I compiled something and it still linked against stock zlib. The ld.so.conf.d trick only affects runtime lookups. If you’re building software from source and want the compiler to pick up our headers and libz.so, install the -devel subpackage and point pkg-config at it:
sudo yum -y install zlib-ng-devel
PKG_CONFIG_PATH=/usr/lib64/zlib-ng/pkgconfig pkg-config --cflags --libs zlib
Alternatively, most ./configure scripts accept --with-zlib=/usr/lib64/zlib-ng or an equivalent hint.
I need to roll back to stock zlib on a specific host. sudo yum -y remove zlib-ng is enough. The ld.so.conf.d/zlib-ng-*.conf file is a %config(noreplace) entry and goes with the package, and ldconfig runs automatically in the postun scriptlet.
An old intel-zlib or cloudflare-zlib install didn’t upgrade on yum update. The Obsoletes chain runs on distro-upgrade-style resolver passes. A plain yum update usually does it, but if you’re stuck, force it: sudo yum -y install zlib-ng on top of the old package will swap it in, then sudo yum -y autoremove cleans up anything stale.
Frequently asked questions
Does zlib-ng change the compression format? No. It emits valid RFC 1951 DEFLATE, RFC 1950 zlib, and RFC 1952 gzip streams, byte-for-byte decodable by any stock zlib on the other end. Your clients and peers don’t need to know anything changed.
Will this break my package manager? No. yum and dnf are built against the same libz.so.1 interface zlib-ng provides. They just run a bit faster when installing and extracting packages.
Is this a subscription package? No. zlib-ng is in the public GetPageSpeed extras repo. A subscription unlocks our paid add-ons (NGINX modules, premium performance libraries), but zlib-ng is free for everyone on a supported distro.
Why aarch64? Because a growing share of the reader base runs servers on Graviton, Ampere, or Raspberry Pi fleets, and those CPUs have an excellent NEON + CRC implementation for zlib-ng to target. The ARM build is not a second-class citizen; it gets the same SIMD paths as the x86 build.
While you’re here
zlib-ng is one of dozens of drop-in performance packages we maintain for RHEL-family distros (and SLES, and Fedora). If you’re optimizing the rest of the stack, two obvious neighbors:
- Brotli static compression for NGINX pre-compresses static assets at deploy time so you serve them without runtime CPU cost.
- jpegoptim powered by MozJPEG is the same “faster drop-in shared library” story, but for JPEG encoding.
Browse the rest of the catalog at the GetPageSpeed repo landing page. If you hit a distro or a package we don’t cover yet, reply to the welcome email and tell us. We take requests.
