Astro, Next.js and WordPress can all support a business website, but they don’t provide the same things. WordPress combines content management with displaying pages. Astro and Next.js are tools developers use to build a site or application; you need to choose and configure the editing environment alongside them. A speed demo therefore isn’t enough to decide. Start with the brief in our custom website guide.
How do Astro, Next.js and WordPress differ?
Compare the complete solution you would receive. A framework without content management isn’t yet an alternative to a configured WordPress site. Equally, having a CMS doesn’t establish the quality of the design or how pages load.
| Choice | What you start with | What needs to be worked out |
|---|---|---|
| WordPress | A CMS with themes and extensions | Theme, plugins, hosting, permissions and maintenance |
| Astro | A framework for pages with selected interactive parts | Content management, publishing, interactive functions and hosting |
| Next.js | A React framework with server and browser components | Content management, data flows, user functions and hosting |
A content-focused site may be a reason to investigate Astro. An application with many connected user functions may warrant looking at Next.js. These are starting points for research, not hard boundaries. Your existing team and useful components matter too.
How are pages put together?
With pre-rendering, pages are made before a visitor requests them. Server processing can happen when a request arrives. Browser code can then provide interaction. A website may combine several approaches.
According to Astro’s islands documentation, an Astro component produces HTML without its own browser runtime by default. You can deliberately add JavaScript for interactive parts. That doesn’t mean every Astro site runs without scripts. Its on-demand rendering guide also explains how some or all routes can be processed on request.
Next.js distinguishes Server and Client Components. Not every part therefore needs to be delivered as interactive browser code. Next.js also supports static export, with limits for features requiring a server. A framework name alone doesn’t determine how much work happens in the browser.
WordPress doesn’t have to rebuild an entire page on every visit either. The WordPress performance documentation describes page caching, which can serve previously generated pages again. The chosen cache policy must suit matters such as signed-in visitors and personal content.
How do you test speed fairly?
Compare the same kinds of pages with the same content and functions. Include a long service page, an image-heavy page and a form. Comparing an empty framework demo with a WordPress site full of adverts mostly tells you about those different pages.
Ask which measurement is being used. PageSpeed Insights distinguishes lab and field data. Lab measurements help investigate problems in defined conditions; field data describes real use. A good lab score doesn’t establish that every visitor receives the same experience.
Record the page, device settings and version used in a trial. Test again after real images, fonts, measurement services and forms have been added. Our explanation of Core Web Vitals covers the terms. Don’t accept a fixed improvement in seconds without a suitable baseline and matching test conditions.
How will your team edit content?
Ask to see the full editorial task: writing, previewing, approval, publishing and correcting a mistake. A text field isn’t enough if someone also needs to schedule pages, manage translations or preview the mobile layout.
With a framework, make that editing environment part of the brief. A separate CMS is one option, but the choice follows from the editor’s work. Our headless CMS comparison looks at assessing these systems against editing tasks.
Also ask when a change becomes visible. Does a new version need building, is information fetched during a visit, or does the site use stored content between updates? Editors needn’t operate the technology, but they should know whether publication succeeded and what to do if old content remains visible.
WordPress can handle both editing and the displayed site. Connecting a separately built front end changes the publishing and operating arrangements. The WordPress, custom and headless comparison helps you assess that architecture decision separately.
Which functions determine the technical choice?
Write out the hardest task, including the exception. A form that sends an email is a different brief from a customer area that displays personal prices, changes data and keeps a checkable record of changes.
Request a trial covering the whole task. For a personal area, consider signing in, access permissions, expired sessions and failed data requests. An attractive page doesn’t prove the underlying processing works. An existing plugin must demonstrate that it meets those requirements too.
Then ask where processing happens and which components are needed. A largely pre-rendered site may still use a separate service for forms. Choosing that service forms part of the solution and its recurring costs.
Assess the team that will maintain the solution. Knowledge of the technology, an understandable setup and a working handover matter more than a preference for the newest framework without a reason tied to the brief.
What changes for security and maintenance?
A pre-rendered public page has different running components from a page that talks to a database on every request. Even so, the CMS, build environment, accounts and form services still need attention. A smaller public component doesn’t automatically make the whole chain secure.
WordPress describes the importance of current software in its security documentation. Frameworks also need someone to maintain dependencies, access and any server functions. There isn’t a general maintenance schedule that follows from the product name alone.
Agree who assesses vulnerabilities, tests changes and performs recovery. Rehearse the restoration procedure. A file backup may be insufficient if content, media or settings live elsewhere. Ask which information is required to restore the agreed service.
How do you compare hosting and costs?
Request estimates for the same scope, including operation, content migration and the expected period of use. A cheap place for static files says little about the total cost of a CMS, forms, search, monitoring and support.
Check whether the chosen hosting supports the features used. Not every application fits a static export. Have subscription terms and limits checked against business use too; a free starting point doesn’t guarantee permanently free operation.
Make change costs concrete. What does a new page within existing blocks cost, and what changes when another data source is added? That shows whether a saving at delivery creates more work for your team or supplier later.
How do you actually get started?
Choose one content page, one editing task and one technically demanding feature. Assess promising approaches against those examples. Record expected costs, maintenance responsibilities and handover alongside the working result.
For website development, TopDevs helps connect those decisions to your brief. Book a call to work out which trial would move your decision forward.
