Why we rebuilt Siargao Booking from WordPress into a fast custom web app

If you visited Siargao Booking a few months ago and you are visiting now, you have probably noticed it feels like a different site. It is. Earlier this year we made the call to rebuild the entire front-end from the ground up, and this is the story of why.

The old site: WordPress + a page builder

The original Siargao Booking ran on a fairly standard WordPress stack: WP for the CMS, a heavy theme on top, and Bricks Builder doing all the layout. It worked. We had listings, hosts could submit properties, travellers could browse the directory. But three things kept getting in our way:

• It was slow. A typical listing page loaded a couple of MB of CSS and JavaScript before anything appeared on screen, even when most of that code was for parts of the page the visitor never scrolled to. Mobile networks in Siargao are not always fast. We were losing people before they even saw the photos.
• The builder owned the page. Every layout decision had to flow through Bricks. Want a custom map page with marker clustering, viewport filtering, and a sticky listing sheet? You either fight the builder or you give up the builder. We kept choosing the fight, and it was exhausting.
• Customisation was brittle. We had layered Cloudflare workers, custom CSS injections, partial-page caching tricks, and a growing list of “do not touch” snippets just to keep things performant. Every plugin update was a small heart attack.

The decision: keep WordPress, replace the front-end

We did not want to throw WordPress out. The admin is familiar, the database structure is solid, ACF gives us a clean way to model listings, and the host community already has accounts there. So we went with what is called a headless setup:

• WordPress stays as the CMS, the user database, the media library, the editorial back office. Nothing for hosts or admins changes, they still log into wp-admin to manage their listings.
• The public site (this one) is a brand-new front-end built with Astro, a modern framework that ships almost no JavaScript by default and prebuilds pages as static HTML.

The two halves talk to each other through a custom REST API we built on top of WordPress. Hosts edit a listing in WP; the listing pages on the public site rebuild automatically.

Why Astro

We looked at Next.js, Nuxt, SvelteKit, and Astro. Astro won for one reason: it ships HTML first and JavaScript second. Most of our pages are content, a listing description, a photo gallery, a map, a blog post. None of that needs React or a SPA. With Astro, every page is rendered as static HTML at build time, then small islands of interactivity (the heart button, the photo slider, the map) get hydrated on demand.

The result: a listing page on the new site loads in roughly a third of the time of the old one, with about a tenth of the JavaScript. On a 4G connection in General Luna, the difference is the difference between a page that feels instant and one that feels broken.

What the rebuild unlocked

The performance was the headline reason, but the real value showed up later, once we had a clean foundation, we could finally build features the old setup could not have supported without months of work:

• A real map browse page with viewport filtering, marker clustering, and a sticky bottom-sheet preview on mobile. Builder-impossible. Astro-trivial.
• A first-class host dashboard with analytics, edit-listing-without-restarting, profile photos, posts, billing, all behind a single login.
• A guest review system with email verification, host moderation, public host replies, ratings on listing cards.
• This blog, served from WordPress but rendered as static HTML for SEO and speed.
• An admin dashboard widget that shows live site activity, top listings by composite score, pending payments to verify, and a one-click “view as host” button so we can debug from a host’s perspective.

The honest trade-offs

Headless is not free. There is more infrastructure to maintain (Vercel for the front-end, the WordPress host for the back-end), the build step adds a couple of minutes of latency between editing and seeing changes live, and we lost the convenience of plug-and-play themes and page builders. For a one-page brochure site, this would be massive overkill.

For a directory of 170+ listings serving travellers from all over the world on patchy mobile connections, it was the right call.

What is next

The rebuild is mostly behind us, the heavy lifting has shipped. The next chapter is about polish: better mobile design, in-app booking inquiries (so leads do not leak to Airbnb), email notifications, structured data for Google, and slowly migrating content from the old site that we have not touched yet.

If you are a host, the most important thing to know is this: your dashboard is now a real product. Edit a listing, see your views, reply to a review, write a blog post, swap your photos, it should all feel fast and obvious. If something does not, tell us. The whole point of building it ourselves was that we can fix it.

Keep reading

If you are new to the platform, start with our pieces on why we built the directory for travellers and how hosting works if you have a property to list.