Picking Up Where We Left Off
The previous article ended with a score of 60/100, along with a list of 4 identified issues and a promise to come back and fix them.
Today, we fixed them — deployed them — and re-ran Lighthouse.
The results exceeded expectations.
4 Fixes in 1 Commit
| # |
Problem |
Solution |
| 1 |
12.4-second redirect chain |
Handled redirects at the infrastructure layer |
| 2 |
JavaScript loading everything at once |
Split loading to prioritize above-the-fold content |
| 3 |
Large PNG images |
Converted 7 images to a lighter format |
| 4 |
Preloading images on every page |
Removed unnecessary preloads, kept only what each page actually needs |
No major refactoring. No infrastructure changes. No new CDN. Just fixing what we knew was wrong.
Results — Real Numbers
Overall Scores
| Metric |
Before |
After |
| Performance |
60 |
86 (best run), median 80–82 |
| Accessibility |
— |
91 |
| Best Practices |
— |
96 |
| SEO |
— |
92 |
Core Web Vitals
| Metric |
Before |
After |
Change |
| FCP |
1.6s (0.95) |
1.3s (0.98) |
▼ 0.3s |
| LCP |
9.1s (0.01) |
4.1s (0.46) |
▼ 5.0s |
| TBT |
570ms (0.52) |
90ms (0.99) |
▼ 480ms |
| CLS |
0 (1.0) |
0 (1.0) |
No change |
| Speed Index |
2.8s (0.96) |
1.6s (1.0) |
▼ 1.2s |
| TTI |
9.6s (0.29) |
4.2s (0.86) |
▼ 5.4s |
Other Metrics That Changed
| Metric |
Before |
After |
| Redirect chain |
12.4s (2 hops) |
0 |
| Main thread work |
3.1s |
1.1s |
| Bootup time |
0.9s |
0.3s |
| Unused JS savings |
300ms potential |
150ms potential |
The most satisfying number isn't the score of 86 — it's the TBT dropping from 570ms to 90ms, because that means the page actually responds faster from the user's perspective.
What We Did — And Why It Worked
1. Eliminated the Redirect Chain — The Biggest Impact
The original problem: when users visited enersys.co.th/, a 2-hop redirect chain consumed 12.4 seconds before the browser even started loading the actual page.
What we did: Adjusted the infrastructure configuration to handle the root path directly — users visiting / now receive content in 1 hop instead of 2 hops + meta-refresh.
Result: LCP dropped from 9.1s to 4.1s — the redirect chain was completely eliminated.
Lesson: Hidden redirect chains in the outer infrastructure layer are problems that performance audits can detect, but you can't find them by looking at code alone — you have to read the Network waterfall with your own eyes.
2. Split JavaScript Loading — Load Only What's Necessary
The original problem: 3 large components below the fold were being loaded together with the initial bundle, even though users couldn't see them yet.
What we did: Separated those 3 components from the initial bundle so they load only when users scroll down to them.
Result: TBT dropped from 570ms to 90ms, bootup time from 0.9s to 0.3s — the initial bundle became smaller, and the JavaScript that needed to be parsed and executed was reduced immediately.
3. Converted Images — 62% Lighter
The original problem: 7 images were still unoptimized PNGs.
What we did: Converted all of them to a modern format.
Result:
| Comparison |
Before |
After |
Reduction |
| Total (7 images) |
588KB |
221KB |
62% |
367KB saved per pageload — with no perceptible difference in image quality.
4. Removed Global Preloads — When "Being Prepared" Becomes a Burden
The original problem: every page on the website preloaded 8 images simultaneously — including images that the page didn't use at all.
Why was this a problem? Preload hints tell the browser to fetch images immediately. But if every page preloads 8 images → they compete for bandwidth with resources that actually matter → the page loads slower.
What we did: Removed all of them, keeping only the hero image preload on the homepage.
Result: Other pages no longer carry the burden of preloading images they don't need — significantly reducing work during initial load.
Bonus: Performance Guard in the CI/CD Pipeline
A one-time fix isn't enough. Every new feature, every new library, every new image has the potential to quietly erode the score without anyone noticing.
We solved this the same way we solve bugs — by adding automated tests to the CI/CD pipeline. If the score drops, the build fails immediately.
Why This Matters
"What isn't measured won't be improved — and what is measured but not monitored will gradually degrade without anyone realizing."
Problems every team encounters:
- Gradual performance regression — Each week adds a small feature. After 3 months, the score drops from 90 to 60 without anyone noticing.
- What looks great on a dev machine may be terrible for users — Developers test on fast machines with fast networks, but real users may be on mobile with 4G.
- SEO gets impacted without anyone knowing — Google uses Core Web Vitals as part of search ranking. If LCP exceeds 4 seconds, it's not just users who are dissatisfied — Google ranks you lower too.
What a performance guard provides:
- Catches regressions immediately — PRs that lower scores get blocked before merge.
- Budget enforcement — Clear thresholds are set; if they're not met, the pipeline errors.
- Historical tracking — Reports are stored every time, making trends clearly visible.
- Builds a performance-first culture — When every PR must pass a performance check, the team thinks about performance from the start, not after deployment.
A Real-World Example
When we first added the performance guard, the pipeline failed immediately because the default settings were too strict, requiring 90+ scores while we were at 73–75 in the CI environment.
What we did was adjust the threshold to match the actual baseline, then gradually raise it as we fixed weak points — the recommended pattern is: start from baseline → prevent regression → gradually raise the bar — not set the threshold impossibly high and skip every build.
What Still Needs Improvement
Let's be honest: 86 is a big improvement from 60, but it's not yet at the target.
LCP Is Still at 4.1 Seconds — Target Is < 2.5 Seconds
LCP dropped from 9.1s to 4.1s — a 55% improvement. But Core Web Vitals defines "Good" as below 2.5s. We're currently in the "Needs Improvement" zone.
The likely cause is how the hero image is being loaded — there's still room for improvement.
Unused CSS Still Has ~300ms Savings Potential
There are still unused CSS rules remaining. More precise optimization should help.
Lessons from This Round of Fixes
Lesson 1: Fix the root cause, not the symptoms
If we hadn't carefully read the Network waterfall in the previous article, we might have wasted time optimizing images or splitting JavaScript without knowing that 12.4 seconds were being lost to a redirect chain in the outer infrastructure layer.
Lesson 2: One infrastructure fix is worth more than 100 lines of code optimization
LCP dropped from 9.1s → 4.1s — most of that came from the eliminated redirect. If we had to pick just one thing to fix, the infrastructure change delivered the biggest results.
Lesson 3: Global preloads are an antipattern that looks helpful but hurts the system
Preloading is a great tool when used in the right place. But "the right place" means preloading only resources that are critical for that specific page — not loading every resource in a shared layout and hoping it helps.
Lesson 4: Measure multiple times, don't trust a single run
The best score was 86, but the median was 80–82. Lighthouse has variability — look at the median rather than the best case.
Summary
In 1 commit, we achieved:
- Performance Score: 60 → 86 (+43%)
- TBT: 570ms → 90ms (84% reduction)
- TTI: 9.6s → 4.2s (56% reduction)
- Main thread work: 3.1s → 1.1s (65% reduction)
- Bootup time: 0.9s → 0.3s (67% reduction)
- Redirect chain: 12.4s → 0
- Performance guard in CI/CD: Monitoring to prevent score regression
Everything happened in under 1 hour — from root cause analysis to deployment and result verification. No sprint planning. No architecture review. Just reading the data carefully and fixing the right things.
How Is Your Organization's Website Performing?
Many organizations we've worked with face similar problems — their website looks great and functions correctly, but is several times slower than it should be, and nobody knows because nobody has ever measured.
These problems have real consequences:
- Google lowers your ranking — Core Web Vitals have been a ranking factor since 2021.
- Customers leave before seeing your content — 53% of mobile users close a page if it takes more than 3 seconds to load.
- Conversion rates drop — Every 100ms of additional load time reduces conversions by 1–2%.
What this case study demonstrates is that most performance problems aren't complex — you just need to know where to look.
At Enersys, we provide Web Performance Audits for organizations that need:
- Detailed root cause analysis, not just looking at scores and guessing
- Performance guards in the pipeline to prevent regression
- Core Web Vitals improvements for better SEO ranking
- Before-and-after measurement with real numbers, not gut feelings
If you'd like to find out what hidden problems your organization's website has — let our team help you analyze it
