Astro Site Quality Improvement Guide, Part 2 - Final Adjustments That Achieved Perfect 100s Across All PageSpeed Insights Categories

Introduction

In the previous Astro Site Quality Improvement Guide, I summarized the large set of improvements applied to the renewed Acecore site. This article is the follow-up.

This article closes the smaller issues that remained after the previous article was published and brings the site to a state where all four PageSpeed Insights categories scored 100 on both mobile and desktop. Beyond score tuning, the work also included deferring GA4 and search UI loading, cleaning up Search Console breadcrumbs and indexing rules, stabilizing icon rendering, and defining where further optimization was no longer worth adopting.

Perfect 100s Across All PageSpeed Insights Categories

As of March 29, 2026, the Acecore home page produced the following results.

Below are the actual PageSpeed Insights screenshots together with the report URLs. In the previous round, I regarded “mobile 99 / everything else 100” as the realistic ceiling. This time, by removing unnecessary third-party beacons and carefully interpreting the meaning of the remaining diagnostics, I was able to reach 100.

Report URLs

To keep the screenshots and directly reopenable evidence together, I am also leaving the report URLs used for this measurement here.

• Mobile report
• Desktop report

Click each image to open the corresponding PageSpeed Insights report.

Mobile Desktop

How impressive is a perfect 100?

A score of 100 can invite the reaction that Performance will always go up if you keep stripping features away, simplifying the UI, and removing outside dependencies. There is some truth in that: a static site often does get faster as you cut more things out.

But this case was not about building the thinnest possible demo page. The site still had to keep GA4, ads, search, ClientRouter, and shared CSS in place while aligning all four categories to 100 on both mobile and desktop. The work was not only about making the site lighter, but about deciding what to keep, what to remove, and what not to touch further.

Of course, a score of 100 does not mean it is absolutely the fastest site in the real world. Real user experience depends on network conditions, devices, regions, and cache state. Even so, it is fair to say that the site has reached a very high level in the sense that the primary Lighthouse audits show no major misses while the required operational pieces are still in place.

Final adjustments that led to perfect 100s

1. Disabled Cloudflare Web Analytics and clarified measurement roles

Cloudflare Web Analytics is useful as a privacy-first and lightweight RUM product, but on Acecore the GA4 side had already been broadly instrumented for CTA clicks, search, contact actions, lead generation, and other events.

After reviewing the roles again, I concluded that on the Cloudflare side the cost of injecting an unnecessary beacon into PageSpeed was now higher than the value it provided. I disabled RUM from the dashboard and confirmed that static.cloudflareinsights.com/beacon.min.js no longer appeared in the production HTML.

However, this was not about throwing away measurement entirely. I still wanted to keep business-event tracking for CTA clicks, search, and contact conversions, so the next step was to keep GA4 while changing when it gets loaded.

2. Kept GA4, but removed it from the initial load

This is where the crucial distinction emerged: the real choice was not simply whether GA4 should stay or go, but whether it had to sit in the initial loading path.

In practice, the gtag entry point stayed available from the start so events could still be queued, but the actual gtag/js script was pushed back to requestIdleCallback and user interaction. The home page also keeps a longer fallback delay, while other pages use a shorter one, so analytics will still load even if the user never interacts.

That change let me keep CTA, external-link, search, and contact measurement intact while avoiding third-party script execution in the earliest rendering phase. The 100-point result was therefore not just the effect of removing the Cloudflare beacon. It also depended on loading GA4 more intelligently.

3. Moved the search UI and Pagefind to on-demand loading

Search is another feature that can quietly weigh down the initial load even if users do not open it right away. Acecore uses Pagefind for full-text search, and in this round I treated it with the same discipline: keep the functionality, but stop paying the cost upfront.

The search modal now loads pagefind-ui.js and its CSS only when the search experience is actually opened. The promise is cached so the assets are not loaded twice, and keyboard shortcuts and query-parameter opening still work normally.

This is not only about a Lighthouse number. It also makes the everyday first render lighter. Search remains available, but it no longer needs to sit on the critical path of every page view.

4. Interpreted the remaining PageSpeed diagnostics

Even after the score reaches 100, PageSpeed can still show diagnostics such as Network dependency tree and render-blocking resources. If you misread these as warnings that must always be eliminated, you can end up chasing low-value optimizations.

The critical chain in this case was roughly:

1. /en/
2. ClientRouter.js
3. BaseLayout.css
4. BaseLayout.js

Of these, the only item that still remained genuinely render-blocking was BaseLayout.css. However, the size is small enough that mobile 100 is still maintained, so for now I categorized it as “a remaining diagnostic that is acceptable.” Putting that judgment into words was itself an important gain, because it gives a clear stopping rule for future tuning.

5. Cleaned up Search Console breadcrumbs and indexing rules

Once PageSpeed had settled, I looked again from the search side rather than the scoring side. That is where Search Console still showed a real mismatch: breadcrumb invalid items were left over, even though FAQ markup was already fine.

To fix that, the BreadcrumbList JSON-LD on listing pages was changed so that explicit breadcrumb items can be passed in rather than inferred too loosely from the path. At the same time, trailing-slash handling was aligned so that canonical URLs, hreflang links, and breadcrumb URLs no longer drift apart.

I also clarified the indexing role of tag, archive, author, and pagination pages. Those pages are useful as navigation surfaces, but they easily become thin or duplicate-style index targets. For that reason, they were aligned with noindex, follow and excluded from the sitemap. This does not instantly erase every crawled-not-indexed report in Search Console, but it does mean that the intended indexing policy is now expressed directly in code.

6. Standardized icon rendering on a shared SVG component

As part of the final adjustment, the project was already moving from UnoCSS icon utilities to a shared SVG-based Icon component. In that transition, dynamic icon classes that remained in ProcessFigure and StatBar were left behind, which caused some places in articles to render as empty circles.

I unified rendering on the component side through Icon and also added an alias that maps the legacy name check-circle to circle-check.

As a result, three practical benefits were obtained:

• It becomes harder for icons to disappear because a dynamic class was missed
• Accessibility attributes such as aria-hidden can be standardized on the SVG side
• Operations become more stable because rendering no longer depends on UnoCSS static analysis

At the same time, blog date parsing and display were also normalized around JST. That is not the headline change of this article, but it matters for stable ordering of same-day posts and for more precise structured data timestamps.

7. What I tested but did not adopt

Once a score of 100 appears, the easy trap is to keep chasing every remaining diagnostic until nothing is left on the screen. I compared several options in that direction, but did not adopt the following ones.

• Splitting BaseLayout.css even further: it might make the diagnostics look slightly cleaner, but mobile 100 is already maintained and the practical gain did not justify the extra complexity.
• Treating the mere presence of network dependency tree as something that had to disappear: a diagnostic being shown is not the same thing as a meaningful user-facing problem.
• Cutting even GA4 to minimize third-party weight: that could make the page slightly lighter, but the loss of business event measurement would be a worse trade-off.

That comparison mattered. It meant the final adjustment was complete not because everything possible had been removed, but because the remaining trade-offs were now explicit and defensible.

Practical lessons from the final adjustment

The biggest gain this time was not simply getting a score of 100. It was reaching a state where I can explain what should be removed and what is acceptable to leave in place.

For example, Cloudflare Web Analytics is worth removing if it is only present by inertia, while GA4 should remain because it is central to business event measurement. But if GA4 remains, it should not necessarily stay on the initial loading path. The better choice is to keep the measurement while changing when the script is loaded.

The same logic applies to search and SEO. Search should remain, but it does not need to ride on the initial payload. Listing pages should remain useful for navigation, but they do not have to be treated as primary index targets. And network dependency tree is not a failure by itself; you have to look inside it and decide whether the remaining chain is reasonable.

I also used AI to widen the set of candidate changes, but the final acceptance criteria stayed grounded in three things: whether measured results actually improved, whether operational cost stayed reasonable, and whether required measurement capabilities remained intact. AI helped broaden the search space; the final call still had to come from measurement and judgment.

If you optimize only for the score, tuning quickly goes too far. This time I was able to organize not only the fixes but also the boundary line for stopping, so it feels fair to say that the Acecore site improvements have, for now, reached a complete state.

Summary

As a continuation of the previous article, the final adjustment covered the following work:

• Confirmed perfect 100s across all PageSpeed Insights categories on both mobile and desktop
• Disabled Cloudflare Web Analytics while keeping GA4 and moving it to deferred loading
• Moved the search UI and Pagefind to on-demand loading and reduced the initial payload
• Interpreted the remaining network diagnostics and clarified which residual issues are acceptable
• Cleaned up Search Console breadcrumb output and indexing rules for listing pages
• Eliminated missing icon rendering by standardizing on a shared SVG Icon
• Rejected low-value extra optimizations and made the stopping point explicit

At least from the perspective of Lighthouse and PageSpeed Insights, the Acecore site has been tuned to the point where it can legitimately aim for top-tier speed. At the same time, the score is not the goal, only the result. Going forward, I will keep both operations and improvements in place so this state does not regress.