Checkout diet · Jan 2025
One animation, 80 KB
Our hosted payment page felt slow on phones. Bundle analysis showed that one animation library was 17% of everything we shipped, and it drew exactly one animation.
- Role
- Frontend engineer
- When
- Jan 2025
- Where
- PayGlocal
- Stack
- ReactWebpackBundle AnalyzerCSS
The situation
A payment page has seconds to earn trust. On mid-range phones the checkout took 2.6 s to first paint and 6.5 s to the largest paint.
What I built
- Analysed the bundle with Webpack Bundle Analyzer and ranked the biggest contributors.
- Swapped the animation library for its lighter build (459 → 426 KB), then replaced it with a few lines of CSS (→ 375 KB).
- Dropped a sanitiser library, deferred loader scripts and preconnected fonts.
- Added a loader script that reports when the payment page fails to start, so monitoring can alert on it.
Try it
459 KB
Production bundle, before
- First paint, mobile
- 2.6 s
- Largest paint, mobile
- 6.5 s
- Loading animation
- still spins
Decisions
Question the dependency, not just its size
The lighter build helped, but the real win came from asking what the library was for. One loading animation does not need a runtime.
Outcome
| What | Before | After | Change |
|---|---|---|---|
| Checkout bundle | 459 KB | 375 KB | −18.3% |
| Mobile first contentful paint | 2.6 s | 1.9 s | −0.7 s |
| Mobile largest contentful paint | 6.5 s | 5.5 s | −1.0 s |
Next projectThe build that ran twice →The merchant dashboard took 12 minutes to deploy and 3 to build locally. The pipeline was building the app twice.