Next.js, Astro or another framework: choosing a business website stack
Astro is a strong candidate for a content-focused business website with a few interactive features; Next.js often suits a larger React application. Neither automatically delivers speed, search visibility or an easy publishing process. The implementation, CMS, hosting and maintenance team matter just as much. This guide shows what to ask for in a proposal and how to tell whether a technology choice serves your business or mainly reflects the supplier’s preferences.
Two agencies can propose the same business website and recommend different technologies. One talks about React; the other emphasizes minimal JavaScript. You need to update case studies, receive inquiries and know who will fix the contact form if it fails. That is the level at which the proposals need to be compared.
This guide draws on vendor and Google documentation checked on October 23, 2026. It is not an original speed benchmark. The recommendations are decision aids rather than a universal ranking. For the wider process, from brief to handover, see our custom website development guide.
01Start with the work the website must support
There are three useful groups of requirements. Content publishing includes services, articles, case studies, careers and language versions. Interaction includes filters, calculators, configurators and bookings. Account-based work includes customer portals, order histories, approvals and private records. For each page, identify which jobs it actually needs to do.
A business presentation with one calculator is different from an application in which customers work with data all day. Equally, adding a login in one section does not mean every public page needs to be generated again for every visitor. A sensible design can serve different parts in different ways without making that distinction the user’s problem.
Add publishing frequency and responsibility to the brief. Who changes a price? Who approves an article? How quickly must an update become public? A supplier recommending a framework before understanding those answers is missing important inputs. Ask them to explain how their choice improves a specific task in your organization.
02Understand what static and server-rendered actually mean
A prerendered page is produced when the site is built, so visitors receive prepared HTML. That suits content which does not need to change for every request. A server-rendered page can respond to the current request, such as showing a signed-in customer’s information. An interactive component in the browser can update a configuration without loading a whole new page.
These approaches can be combined. A public service page might be prepared in advance, while its calculator responds to inputs and its contact form sends data to a server-side service. “Will the site be static?” is therefore an incomplete question. Ask which data is loaded when, where it comes from and what happens if that source is unavailable.
Freshness is the practical issue. When an editor changes a price or removes a job vacancy, they need to know when visitors will see it. Ask the proposal to describe publishing, caching and rollback. Fast pages with an unclear update process can create more work than a less impressive technical setup that the team can reliably operate.
03Where Astro is a useful candidate
Astro focuses on content-driven websites. Its islands architecture can separate interactive components from the rest of a page. A small calculator does not have to make the surrounding content behave like an entire client-side application.
That can be a good starting point when most of the site consists of copy, photographs, product information and case studies. Consider a manufacturer with a project catalog, several languages and an inquiry form. Judge the advantage by the delivered experience: prompt access to content, a usable editor and manageable upkeep.
Astro is not limited to pages that never change. It supports on-demand rendering for selected routes or the site as a whole through an appropriate adapter. That does not make it the best choice for every application. When many screens share complex state, evaluate the architecture and the team’s experience rather than the speed of a simple demo.
04Where Next.js makes sense
Next.js is a candidate when the business needs a substantial React-based product and has a team able to maintain it. Server and Client Components separate server work from interactive browser features. Where that boundary is drawn affects how much code visitors download.
Imagine a customer workspace in which people revise a budget, track requests and resume unfinished tasks. A consistent environment and shared components can have real value. A ten-page public website may not need all of that machinery. Headroom for future features is useful when it follows a credible roadmap, rather than an unspecified promise that the business might need anything one day.
Next.js also supports a static export. That mode excludes features requiring a runtime server, such as Server Actions. The choice is not simply “Next.js with a server” versus “another framework without one.” Ask which mode is proposed and where its limits sit, so a later preview or form requirement does not quietly rewrite the operating plan.
05Ask the same questions about the alternatives
The shortlist does not have to stop at two names. SvelteKit also exposes choices around prerendering, server rendering and client behavior. If a supplier knows it well and can demonstrate operation and handover, assess it against the same brief. Apply the same discipline to Nuxt, a conventional server-rendered site or a managed website system.
A popular technology is not automatically appropriate, and a less familiar one is not automatically wrong. Check whether another team could take over, how dependencies are maintained and which parts are unique to the supplier. An undocumented proprietary framework can be a more significant risk than choosing between several established projects.
| Main requirement | What the supplier should demonstrate | A possible direction |
|---|---|---|
| Articles, service pages and case studies | Editing, previews, publication and content performance | A content-focused approach, such as Astro |
| A substantial signed-in workspace | State, permissions and data handling | An application framework, such as Next.js |
| A straightforward standard website | Easy administration and low operating complexity | An established CMS or managed system |
| An existing site that works reliably | The specific limitation a replacement will remove | Targeted improvements before a rebuild |
06Choose the editing experience separately
A CMS is where people manage the content. A framework name does not tell you whether an editor can add a table, prepare a translation or restore an earlier version. Astro, for example, documents integrations with different CMS products. Editing is a separate design decision, with potentially separate licensing and operating costs.
Let the person who will actually run the site edit a realistic sample article. Ask them to replace an image, add alternative text, insert a link and check the preview. Then have them try approval and publication. A demonstration driven entirely by a developer does not establish everyday usability.
A multilingual site needs a clear distinction between shared information and independently managed versions. A product’s technical specification may be common, while its description, contact person and local offer differ. Ask about exporting content, images and relationships too. Copying paragraphs into a spreadsheet is not a complete website backup.
07Search visibility needs accessible content and sound URLs
Google can process JavaScript, but its documentation still recommends considering server-side or prerendered output. Not every crawler runs JavaScript. Important content and links should be reliably available rather than depending on a complicated sequence of interactions.
A framework change will not fix an unclear offer, missing service pages or poor internal links. Google also says that good page experience does not guarantee top rankings. Technical quality helps useful content work; it does not replace the usefulness.
For a rebuild, ask for a mapping between old and new URLs, redirects, page titles, canonical addresses and language relationships. Check error pages and the handling of a test environment that should stay out of search. Migration belongs in the original proposal, not a cleanup task after launch. Our SEO strategy guide covers the wider content context.
08Measure a real page with real content
An empty demonstration without photography or measurement scripts reveals little. Ask for tests using the actual hero image, fonts, form and analytics under the relevant consent setting. On a phone, test loading, opening the menu and completing a form. One laboratory run does not describe every visitor’s experience.
Google’s Core Web Vitals cover loading, responsiveness and visual stability. The recommended good thresholds are LCP within 2.5 seconds, INP within 200 milliseconds and CLS no higher than 0.1. Web.dev describes assessing the 75th percentile, with mobile and desktop considered separately.
Those numbers are not a framework popularity contest. A slow external chat service, an oversized photograph or unnecessary code can undo a sound foundation. Agree budgets for images and scripts, a post-launch measurement process and responsibility for regressions. If marketing adds a new service, someone should be assigned to assess its impact.
If you compare two technologies, keep content and functionality comparable. Otherwise, the test may mostly measure differences between two developers or two sets of images. Our 3-second rule guide explains why the visitor’s actual experience matters more than an attractive score in a sales proposal.
09Treat hosting and security as design decisions
Next.js can, according to its deployment documentation, run with a provider supporting Node.js and through other supported approaches. Operating it yourself adds responsibility: the self-hosting guide covers matters such as a reverse proxy. Freedom to choose a platform does not mean the service runs without operational work.
Ask for a breakdown of hosting, database, storage, CMS, messaging, monitoring and usage limits. What happens during a traffic spike or when a quota is exhausted? Which accounts belong to you, and which services are resold by the supplier? Without those answers, it is difficult to compare either cost or the practical ability to leave.
Prepared public pages can reduce some runtime complexity, but security does not end there. Forms, administration, accounts, integrations and the build process still need protection. Agree update responsibilities, backups, restoration checks and incident response. Handing over a CMS password is different from handing over an operable website.
10Compare the cost over the period you will use it
Without a brief, it is not credible to claim that Astro costs a fixed percentage less than Next.js. Content, design, editing, integrations, testing, migration and access to skilled people all affect cost. A complicated publishing workflow may outweigh the hosting difference. Cheaper infrastructure does not necessarily make the website cheaper.
Create the same cost breakdown for each proposal: initial delivery, recurring services, maintenance, ordinary content changes and planned development. Use a common period, such as three years, and identify assumptions for uncertain items. Do not compare a one-off investment only with the first month of a subscription. Separate necessary costs from optional services.
Include the time of your own staff. If each small update requires a developer ticket, it creates an ongoing expense and delay. An unrestricted editor can create a different burden when people break the layout. Well-designed blocks give editors useful freedom while protecting the structure. Ask the supplier to price an ordinary task, such as adding a service page in two languages.
Ask about the cost and process of handover as well. Who controls the repository, domain, hosting accounts, media and documentation? Can another team build and deploy the project? Supplier exit terms deserve the same attention as the framework. Our guide to taking over a website from a supplier provides a practical checklist.
11Three businesses can reasonably choose different routes
A manufacturer with a project catalog. Content quality, languages and straightforward project publishing create most of the value. Astro may fit if the supplier also delivers a useful CMS and publishing process. A signed-in service portal can remain separate. The entire public presentation does not need to become an application in anticipation of hypothetical features.
A service provider with a customer workspace. Customers regularly revise records, upload files and follow progress. Next.js may fit a React-based team capable of handling permissions and operations. The presence of a login still does not mean public pages require the same rendering approach as private screens.
A small company with a few stable pages. A well-supported managed system may be more sensible than a custom technical foundation. If the current site serves its purpose, fix specific weaknesses first. Rebuilding for a more fashionable name has a weak business case. These are illustrative decision scenarios, not descriptions of individual client projects.
12Ask for a demonstration before signing
Choose a typical page and one difficult task. Have the supplier demonstrate the editor’s workflow, mobile behavior, form submission and an error case. For dynamic features, add permissions and a lost connection. The demonstration should use representative content and the publishing process intended for the finished site.
Write down acceptance conditions: working links, a successful inquiry or purchase, accessible core tasks, URL migration, measurement and recovery. Establish who handles faults after launch. A supplier who can answer these questions gives you stronger decision evidence than a presentation filled with technology logos.
The final question is straightforward: which option meets the needs at a proportionate cost, and which can the business operate? The answer may be Astro, Next.js or something else. A good choice has an understandable reason behind it, rather than a name that happens to be everywhere this month.
13Frequently asked questions
Is Astro always faster than Next.js?
You cannot draw that conclusion without a comparable project. Content, client-side code, external services, hosting and implementation affect the outcome. Compare equivalent features and measure real visitors as well.
Can a static website have a form or calculator?
Yes. Prepared content can include an interactive browser calculation and a form connected to a server-side service. The design still needs to cover data handling, failure cases and operation, not just page output.
Does Next.js require Vercel?
There are several supported deployment approaches. Choose a specific operating model around the required features, team responsibilities and cost. Establish who manages the infrastructure and handles incidents.
Will switching frameworks improve search rankings?
The switch itself is no guarantee. Technical quality must support relevant content, sound URLs and a useful experience. A migration also needs to protect existing pages and links.
Will I be able to update the content myself?
That depends on the CMS and its design, not simply on the framework. Try editing a real page, previewing it, publishing it and restoring an earlier version before signing.
When should we avoid rebuilding the current site?
When there is no specific problem or requirement that a rebuild will resolve. Consider a smaller improvement to content, editing, performance or forms first. A complete change also brings migration, testing and new operating responsibilities.
14Sources
- Astro: framework principles
- Astro: islands architecture
- Astro: on-demand rendering
- Astro: connecting a CMS
- Next.js: Server and Client Components
- Next.js: static exports
- Next.js: deployment and self-hosting
- SvelteKit: page options
- Google: JavaScript SEO basics
- Google: page experience
- Google: Core Web Vitals and web.dev: measuring Web Vitals
Documentation checked on October 23, 2026. Business scenarios are editorial recommendations. Confirm specific capabilities and operating requirements for the selected version and deployment approach.