Astro Lighthouse 100 Performance Checklist

Astro lighthouse 100 performance checklist is a practical way to describe the set of decisions that help an Astro site reach top Lighthouse scores without adding unnecessary client-side weight. It is not a single feature inside Astro; it is the discipline of building pages so they stay fast in production, not just on a local machine.

For merchants and developers, the point is simple: a site can feel instant in development and still lose performance in the real world if images, fonts, scripts, and hydration are not controlled. The checklist is how you keep Astro’s default speed advantage intact as the site grows.

Key takeaways

• Astro is fast by default, but production performance depends on implementation choices.
• The biggest Lighthouse losses usually come from over-hydration, heavy media, and third-party scripts.
• A 100 score is possible, but the real goal is a stable, fast user experience on mobile and desktop.
• Performance work in Astro is mostly about deciding what should stay static and what truly needs JavaScript.
• The best checklist is repeatable: measure, trim, test, and re-check after every meaningful change.

What is it?

At a practical level, an Astro lighthouse 100 performance checklist is a review framework for keeping an Astro site lean enough to score well on Lighthouse. It combines architectural choices, asset handling, and testing habits into one process. The checklist matters because Astro’s performance model only works when teams preserve its low-JavaScript approach instead of gradually turning the site into a heavier app.

A useful example is a marketing site with a hero section, product highlights, a blog, and a newsletter form. The content itself can stay static, while only the form or a small interactive widget hydrates on the client. If the team adds a large animation library, loads every component with client:load, and ships uncompressed images, the site can lose the advantage Astro gave it in the first place.

That is why the phrase is best understood as a workflow, not a badge. The checklist helps you ask the right questions before launch: Does this component need JavaScript? Is this image larger than it needs to be? Are fonts delaying text rendering? Are we loading scripts that could wait? Those questions are the difference between a site that merely uses Astro and a site that benefits from it.

For content-heavy teams, this also connects to structure. A well-organized site with clean content collections, predictable layouts, and limited interactive surface area is easier to keep fast. If you want a broader content-structure foundation, the Astro Content Collections guide is a useful companion.

Why it matters

The business case for performance is straightforward: faster pages reduce friction. When a merchant’s homepage, collection page, or article opens quickly, visitors can read, browse, and act sooner. On mobile connections, every extra script or oversized image makes that first interaction slower, and that delay can affect engagement before a shopper even sees the offer.

The technical case is just as important. Lighthouse measures more than one thing, but the score is strongly influenced by render-blocking resources, main-thread work, and layout stability. Astro gives you a strong starting point because it ships less JavaScript by default, yet the score still depends on how the site is assembled. A page with too many hydrated components can behave more like a traditional app than a static-first site.

There is also a maintenance angle. Performance is easier to preserve when the team has a checklist than when they rely on memory. In real projects, speed often degrades slowly: a new animation here, a chat widget there, a font swap, a tracking script, an extra gallery, and suddenly the page no longer feels as light as it did at launch. The checklist gives developers and merchants a shared standard for deciding what earns a place on the page.

For stores and content brands, this matters beyond Lighthouse itself. A fast page improves the odds that users will reach the next step in the journey, whether that is reading more, viewing a product, or submitting a form. If you are comparing architecture choices that affect speed, Astro Islands architecture explains why selective interactivity is such a strong default.

A useful way to think about the impact is in terms of risk control. Without a checklist, every new feature can quietly increase page weight. With a checklist, each addition has to justify its cost. That makes performance less fragile, especially for teams that publish often or work across multiple pages and templates. It also helps non-technical stakeholders understand why a seemingly small change, like adding a new embed or a second font family, can have a measurable effect on the experience.

How it works

Astro’s performance model works by rendering as much as possible to HTML and only adding JavaScript where interactivity is truly needed. That means the browser can paint the page quickly, and the main thread is not burdened with a large framework bundle before the user can do anything useful. The checklist is built around preserving that advantage.

The first step is deciding what stays static. Content blocks, navigation, product copy, editorial pages, and most layout elements usually do not need client-side JavaScript. If a component only displays information, it should remain server-rendered or static. The second step is deciding which interactive pieces deserve hydration. A search field, a filter panel, a cart preview, or a form may need JavaScript, but not necessarily at the same moment or with the same priority.

Hydration timing is the key lever

Astro lets you control when interactive components become active. That timing matters because hydration consumes browser resources. If everything hydrates immediately, the page may look fast but still feel sluggish when users try to interact. If hydration is delayed intelligently, the browser can prioritize the visible content first and load secondary interactions later.

A practical workflow is to classify components by urgency. First-screen essentials should be treated differently from below-the-fold widgets. A navigation menu may need early activation, while a testimonial carousel or comment section can wait until the browser is idle or the component becomes visible. This is the main reason the checklist is so useful: it forces teams to make hydration decisions instead of defaulting to “interactive everywhere.”

Assets matter as much as components

The second mechanism is asset control. Lighthouse does not care that your site is built with a modern framework if you still ship large JPEGs, unoptimized fonts, or heavy scripts from embeds. Astro can only do so much if the page is loaded with unnecessary bytes. The checklist therefore includes image sizing, font loading, script placement, and the removal of unused code.

This is where teams often overestimate the framework and underestimate the page. Astro reduces baseline overhead, but a poorly managed asset pipeline can still drag the score down. The right mental model is: Astro gives you a fast shell, and the checklist keeps the shell from being filled with avoidable weight.

A useful way to think about the mechanism is in layers. First, the HTML should be ready quickly. Second, the visible content should not wait on unnecessary scripts. Third, the browser should not waste time decoding oversized media or parsing code that the visitor may never use. When those layers are aligned, Lighthouse usually improves because the page becomes easier for the browser to render, stabilize, and interact with.

Another important detail is that Lighthouse rewards consistency, not just one good-looking page. If your homepage is optimized but your product templates or article pages are not, the site can still feel uneven. A checklist works best when it is applied across templates, because that is how teams prevent one fast page from hiding a slower system underneath.

Use cases

A common use case is a marketing or product launch site. These sites usually need strong first impressions, clear messaging, and a few interactive elements such as a signup form or a pricing toggle. The checklist helps teams keep the landing page light while still supporting the conversion actions that matter. In this scenario, the biggest win is usually not adding more optimization tricks; it is avoiding unnecessary complexity.

Another use case is a content site or blog. Editorial pages are especially well suited to Astro because most of the page is read-only content. The checklist here focuses on image discipline, typography, and limiting embeds that pull in large third-party payloads. If the team uses structured content, the page becomes easier to standardize and easier to keep fast as the library grows.

A third use case is a hybrid storefront or headless commerce front end. These sites often need more interactivity than a simple brochure site, because shoppers may filter collections, open menus, or interact with product tools. The checklist becomes a guardrail: it helps the team decide which interactions belong on the client and which can stay server-rendered or be deferred. That balance is especially important when the site must feel polished on mobile while still supporting commerce behavior.

There is also a useful internal use case: teams can use the checklist as a release gate. Before a page goes live, someone reviews whether any new component changed the hydration profile, whether a new image set was optimized, and whether a third-party script is really necessary. That kind of gate is especially valuable for agencies, in-house marketing teams, and merchants who publish frequently. It keeps performance from becoming an afterthought.

In all three scenarios, the checklist is less about chasing a vanity score and more about controlling complexity. The more a team adds, the more valuable it becomes to have a repeatable standard for what is allowed to hydrate, what must stay compressed, and what should be deferred.

How to implement or apply it

Start with a baseline Lighthouse audit on a production-like build, not just local development. Local builds can hide issues that show up once real assets, scripts, and deployment settings are in place. Record the main problem areas first: excessive JavaScript, slow images, font delays, layout shifts, or third-party scripts that block rendering. The goal is to identify the biggest sources of friction before making changes.

Then work through the page from top to bottom. Ask whether each component needs client-side behavior at all. If it does not, keep it static. If it does, consider whether it needs to hydrate immediately or can wait. This is where selective interactivity pays off. A component that is visible but not urgent can often be delayed without affecting the user’s ability to understand the page.

A practical order of operations

1. Remove JavaScript from display-only components.
2. Reduce the number of hydrated islands on the page.
3. Compress and resize images for their actual display size.
4. Check fonts for loading behavior and unnecessary variants.
5. Audit third-party scripts and keep only what is essential.
6. Re-test after each meaningful change.

That order matters because it targets the largest likely wins first. It is easy to spend time polishing a small issue while a heavy script or oversized image continues to dominate the page weight. You want to fix the structural problems before you fine-tune.

If your site uses a theme or starter, treat the checklist as part of the launch process, not a one-time cleanup. A theme can give you a strong base, but the final score still depends on how you configure it and what you add later. For teams choosing a performance-conscious starting point, the Astro Themes category can be a useful place to compare options.

Decision criteria for common tradeoffs

Use client:load only when the interaction is needed immediately on first view, such as a primary navigation element or a search box that users are likely to use right away. Avoid it for decorative widgets, secondary forms, and below-the-fold features. Use client:idle when the feature matters but does not block the page from being useful. Use client:visible when the component is far enough down the page that loading it early would only waste resources.

The same logic applies to media and embeds. Use a local image pipeline when the image is part of the page design and can be resized, compressed, and served in modern formats. Avoid dropping in a full-size asset just because it is available. Use third-party embeds only when they are truly necessary, and consider whether a lighter link, preview, or deferred load would serve the same purpose.

A good implementation habit is to document these decisions in the repo or content workflow. If a component is intentionally hydrated, note why. If a script is allowed on a page, note what business function it serves. That documentation makes future reviews faster and reduces the chance that a later edit reintroduces the same problem.

Common mistakes and pitfalls

The most common mistake is over-hydration. Teams see a component that could be interactive and immediately attach client:load to it, even when the interaction is not needed on first paint. That approach can erase Astro’s advantage quickly. A page with too many immediately hydrated components may still be technically correct, but it will not feel as fast as it should.

Another pitfall is assuming images are “good enough” because they look fine in design review. Lighthouse is sensitive to media weight, especially on mobile. A visually acceptable image can still be too large for the space it occupies. If the file is bigger than the display requirement, the browser pays for bytes the user never sees.

Fonts and scripts are the other repeat offenders. Multiple font families, too many weights, and early-loading third-party scripts can all add friction before the page becomes useful. This is especially easy to miss when a site accumulates marketing tools over time. Every new script may seem small in isolation, but together they can create a noticeable delay.

A final mistake is treating the score as the goal instead of the user experience. Lighthouse is a diagnostic tool, not the product itself. If a change improves the score but harms readability, accessibility, or the actual flow of the page, it is not a good trade. The checklist should support the site’s purpose, not override it.

One more subtle pitfall is testing only once. Performance regressions often arrive through small changes, not major redesigns. A new banner, a revised font stack, or a marketing pixel can shift the page enough to matter. The fix is not to avoid change; it is to make re-testing part of the release habit.

A practical fix for these pitfalls is to assign ownership. Someone should be responsible for hydration decisions, someone for media optimization, and someone for third-party review. When no one owns performance, the checklist becomes a document people admire but do not use. When ownership is clear, the checklist becomes part of the normal publishing process.

Best practices and quick checklist

The best practice is to treat performance as a design constraint. Decide early that the page will stay lean, and make every new feature justify its cost. That mindset is more effective than trying to optimize after the page has already grown heavy. It also makes reviews easier because the team has a shared standard.

A second best practice is to separate content from interaction. Keep content blocks static whenever possible, and isolate the few elements that truly need JavaScript. This fits Astro’s strengths and makes future maintenance simpler. When a page is built this way, it is easier to reason about what changed when performance shifts.

Quick checklist

• Keep display-only components static.
• Hydrate only the interactions users need.
• Delay non-urgent widgets when possible.
• Resize and compress images for actual display.
• Limit font families and font weights.
• Audit third-party scripts before launch.
• Re-run Lighthouse after major changes.
• Test on production-like builds, not only locally.

A third best practice is to review performance as part of content and feature updates, not only during technical audits. A new section, embed, or widget can change the page profile enough to matter. If you want a broader view of how performance affects search and user experience, Core Web Vitals is a useful companion topic.

For teams that want a simple operating rule, use this: if a change adds bytes, it must earn its place. That does not mean every page must be stripped bare. It means every asset, script, and component should have a clear reason to exist, and that reason should be stronger than the cost of loading it.

A final checklist pass can be as simple as asking four questions: Does this need to be interactive? Does it need to be interactive now? Can it be smaller? Can it wait? If the answer to any of those questions is no, the page probably has room to improve.

From practice — illustrative scenario (hypothetical, not a client project)

Illustrative example — not a real client project: imagine a merchant launching a new Astro-based product site with a homepage, a few editorial pages, and a simple newsletter form. The team is happy because the site feels quick in development, and the first Lighthouse run looks promising. But after adding a testimonial slider, a chat embed, a tracking script, and several high-resolution images, the production score drops enough that the page no longer feels as clean as the team expected.

A typical merchant might start by looking at the score and assuming Astro is not doing its job. A developer on the same project would probably see a different issue: the site is still using Astro, but the implementation has drifted away from the zero-JavaScript default. The slider hydrates immediately, the chat widget loads early, the images are larger than their display area, and the fonts include more variants than the design actually needs.

The practical approach is to rebuild the page around priority. The content sections stay static. The newsletter form hydrates only where interaction is required. The slider becomes optional or delayed. The chat widget is moved lower in the load order or removed from the landing page entirely if it is not essential. Images are resized to match their containers, and font usage is reduced to the minimum needed for the design system.

At that point, the team can make decisions in a repeatable order. First, they identify which elements are essential to the page’s purpose. Second, they separate those elements from decorative or secondary features. Third, they decide whether each interactive piece should load immediately, wait for idle time, or appear only when visible. Fourth, they re-test the page after each change so they can see which adjustment actually moved the score.

The takeaway is not that every feature must be removed. It is that each feature needs a cost check. If a component improves the page but adds weight, the team should decide whether the value is worth the trade. The checklist gives that decision a structure, which is what keeps a fast Astro site fast after launch.

Related concepts and further reading

If you are using this checklist as part of a broader Astro performance workflow, these guides help connect the dots between architecture, content, and user experience.

• Astro Islands architecture — understand how selective hydration keeps pages lean.
• Core Web Vitals — see how Lighthouse work maps to real user experience signals.
• Astro Content Collections guide — useful when you want structured content that is easier to keep fast.
• Astro docs on performance — official reference for framework behavior and implementation details.
• Astro Themes — compare starting points that can support a performance-first build.