Affected Page URL
https://www.php.net/releases/8.5/en.php
Describe the bug
The PHP 8.5 release page causes unusually high and continuous GPU usage while the page is idle.
On my system, simply leaving the page open results in approximately:
- Firefox: 75–100% GPU usage
- Microsoft Edge: ~12% GPU usage
There is no user interaction occurring and the page is otherwise completely idle.
The issue appears to be caused by the animated SVG used as .hero-bg in the hero section.
The SVG contains three full-size <rect> elements using radial gradients. Each one is wrapped in nested <g> elements and several independent infinite CSS transform animations are applied:
.hero-orb-1-x { animation: hero-orb1-x 10s linear infinite alternate }
.hero-orb-1-y { animation: hero-orb1-y 10.5s linear infinite alternate }
.hero-orb-1-r { animation: hero-orb-rotate-fwd 7s linear infinite }
.hero-orb-2-x { animation: hero-orb2-x 11.5s linear infinite alternate }
.hero-orb-2-y { animation: hero-orb2-y 12s linear infinite alternate }
.hero-orb-2-r { animation: hero-orb-rotate-fwd 12s linear infinite }
.hero-orb-3-x { animation: hero-orb3-x 12.5s linear infinite alternate }
.hero-orb-3-y { animation: hero-orb3-y 6s linear infinite alternate }
.hero-orb-3-r { animation: hero-orb-rotate-rev 9s linear infinite }
Steps to reproduce
- Open https://www.php.net/releases/8.5/en.php in Firefox.
- Leave the page idle on the hero section for a few seconds.
- Open Windows Task Manager and check GPU utilization.
- Observe that GPU utilization rises to approximately 100% and remains very high while the page is visible.
- Disable or remove the
.hero-bg SVG / its animations in DevTools and observe the GPU utilization.
Expected behavior
An idle release/documentation page should consume negligible GPU resources.
A purely decorative background animation should not continuously saturate or significantly load the GPU.
Screenshots
Additional context
The screenshot was taken in Firefox on Windows with an NVIDIA GeForce RTX 4070 Laptop GPU. GPU utilization reaches 100% while the page is simply displayed and no user interaction is taking place.
For comparison, Microsoft Edge on the same page uses approximately 12% GPU, which is substantially lower but still unusually high for a decorative background effect.
The performance issue appears to be associated with the animated .hero-bg SVG. It contains three full-size radial-gradient rectangles with multiple nested, continuously running CSS transform animations.
The current implementation also does not appear to provide a prefers-reduced-motion fallback for these animations.
Affected Page URL
https://www.php.net/releases/8.5/en.php
Describe the bug
The PHP 8.5 release page causes unusually high and continuous GPU usage while the page is idle.
On my system, simply leaving the page open results in approximately:
There is no user interaction occurring and the page is otherwise completely idle.
The issue appears to be caused by the animated SVG used as
.hero-bgin the hero section.The SVG contains three full-size
<rect>elements using radial gradients. Each one is wrapped in nested<g>elements and several independent infinite CSS transform animations are applied:Steps to reproduce
.hero-bgSVG / its animations in DevTools and observe the GPU utilization.Expected behavior
An idle release/documentation page should consume negligible GPU resources.
A purely decorative background animation should not continuously saturate or significantly load the GPU.
Screenshots
Additional context
The screenshot was taken in Firefox on Windows with an NVIDIA GeForce RTX 4070 Laptop GPU. GPU utilization reaches 100% while the page is simply displayed and no user interaction is taking place.
For comparison, Microsoft Edge on the same page uses approximately 12% GPU, which is substantially lower but still unusually high for a decorative background effect.
The performance issue appears to be associated with the animated
.hero-bgSVG. It contains three full-size radial-gradient rectangles with multiple nested, continuously running CSS transform animations.The current implementation also does not appear to provide a
prefers-reduced-motionfallback for these animations.