"Our website is sluggish," "We are overwhelmed by constant WordPress updates," "We dread security vulnerability notifications"—many companies managing corporate websites struggle with these persistent challenges. When rebuilding our own website at GleamHub, we adopted a Jamstack architecture alongside a headless CMS, successfully tripling page speed while cutting operational costs in half. In this article, we share practical insights based on the background, architectural decisions, and specific metrics from that initiative.
Why we moved away from WordPress
Prior to the redesign, our site was built on WordPress. While it offered high flexibility for updating content and its rich plugin ecosystem was initially attractive, several structural issues surfaced as operations continued.
Degradation in page speed. With WordPress, every request repeats a cycle of PHP processing, database queries, and HTML generation. As plugins accumulated, this processing grew increasingly heavy, consistently recording an LCP (Largest Contentful Paint) of around 4.8 seconds. Google's benchmark classifies 2.5 seconds or less as Good, meaning our performance was clearly putting us at a disadvantage in terms of both SEO and user experience.
Surging maintenance costs. Updates to the WordPress core, themes, and plugins occurred frequently, turning compatibility checks, backups, and verification in staging environments into routine monthly tasks. Without dedicated developers on staff, this overhead cannot be overlooked.
Security risks. Powering roughly 40% of CMS-driven websites globally, WordPress is an attractive target for attackers. Responding to incidents such as malware infections, brute-force attacks, and plugin vulnerabilities represented significant latent overhead and risk.
We evaluated migrating to Jamstack because we determined that it could resolve these three challenges at the architectural level. Jamstack fundamentals are explained in detail in this article, which you can consult if you would like to explore the concepts first.
The chosen technology stack
The technology stack following the migration is structured as follows:
| Layer | Technology | Selection rationale |
|---|---|---|
| Framework | Astro | Zero-JS-by-default architecture via Islands, fast build times |
| Headless CMS | microCMS | Japanese UI, API-first design, high support quality |
| Hosting | Google Cloud Storage + CDN | Static file delivery, global edge network |
| CI/CD | Cloud Build | Automating code changes, builds, and deployments |
The reason we chose Astro lies in its core philosophy of shipping zero JavaScript by default. While React and Vue generate substantial JS bundles for state management and interactive components, Astro outputs static HTML and delivers minimal JS only where interactivity is needed via Islands. This directly contributed to our LCP improvements.
The reason we chose microCMS is its ease of use from an operational perspective. It is a domestic headless CMS offering an administrative dashboard and support in Japanese. Its API design is straightforward, and official tutorials are available for integrating it with Astro. As of late 2025, it has been adopted by more than 13,000 companies, boasting an extensive track record of enterprise adoption.
We have published a step-by-step implementation guide covering the integration of Astro and microCMS in a separate article, which you can reference once you enter your implementation phase.
Three core principles established during the design phase
1. Complete separation of content and presentation
microCMS solely serves content via its API. How that content is presented is handled entirely by the frontend (Astro). Thanks to this decoupling, even if design overhauls or framework migrations take place in the future, content assets—such as articles, images, and metadata—can be carried over untouched. In WordPress, content is tightly coupled to themes, introducing content migration risks whenever design modifications occur.
2. Thorough commitment to build-time static generation
A build is triggered whenever content is updated, exporting every page as static HTML. Requests from users are served instantly from CDN caches, eliminating server-side processing entirely. Compared to our WordPress era, TTFB (Time to First Byte) improved dramatically.
3. Minimizing risk through incremental migration
Rather than migrating everything in a single stroke, we took an incremental approach: new content was launched on the new stack, while existing content was migrated in phases. This ensured the site remained online throughout the migration, giving the team sufficient time to review, refine, and adapt to the new system.
Improvements measured in numbers
Below is a comparison of key metrics measured three months post-migration.
| Metric | Before migration (WordPress) | After migration (Jamstack) | Improvement rate |
|---|---|---|---|
| LCP (Mobile) | 4.8 s | 1.5 s | Approx. 3.2x faster |
| TTFB | 1.2 s | 0.08 s | Approx. 15x faster |
| PageSpeed Insights score | 48 (Mobile) | 94 (Mobile) | +46 points |
| Monthly hosting expenses | Approx. ¥15,000 | Approx. ¥3,000 | Approx. 80% reduction |
| Monthly maintenance labor | Approx. 12 hours | Approx. 2 hours | Approx. 83% reduction |
| Security incident responses | 3–4 incidents/year | 0 incidents | — |
Reducing LCP from 4.8 seconds to 1.5 seconds transformed our Google Core Web Vitals rating from Poor to Good. This directly translated into improved SEO evaluations, driving an organic traffic increase of approximately 35% within six months of migration.
The reduction in hosting costs stemmed from shifting from a dynamic server (VPS) to static file hosting (Cloud Storage). Storing and transferring static files is significantly cheaper than maintaining a comparable VPS, and because CDNs scale automatically during traffic spikes, concerns over unexpected expenses were eliminated.
Transformations in operational workflows
The most significant change following the Jamstack migration occurred in our content publishing workflow.
Before migration: Content editor logs into WordPress dashboard → drafts/edits post → reviews preview → publishes (reflected instantly)
After migration: Content editor edits in microCMS dashboard → saves draft → reviews via preview URL → clicks publish → triggers webhook → Cloud Build runs → static files generated → deployed to CDN (reflected in 2–3 minutes)
Because publishing requires a 2- to 3-minute build window, there is a perceptible wait when someone wants immediate reflection. However, this comes with the secondary benefit of preventing accidental publishing mistakes. By operating our editorial calendar with build latency in mind, our overall publishing workflow became much more structured.
Freeing technical staff from non-essential maintenance tasks—such as updating WordPress plugins, applying security patches, and checking backups—allowed those engineering hours to be redirected toward feature development, performance optimization, and SEO initiatives.
Pitfalls to watch out for during a Jamstack migration
Jamstack is not an optimal solution for every single use case. Below is an overview of key points to keep in mind prior to migration.
Build times with large content volumes. When site volume reaches thousands or tens of thousands of pages, builds take longer. With Astro, it is essential to leverage incremental build mechanisms or architect webhooks on the headless CMS side so that only modified pages are rebuilt.
Supplementing dynamic functionality with serverless functions. Areas requiring dynamic processing—such as user login, form submissions, and search—are implemented using serverless functions like Vercel Functions or Cloud Functions. Discerning what can be rendered statically versus what requires dynamic handling is critical to effective architecture.
Monitoring CMS API rate limits. Free and low-tier plans of headless CMS platforms impose caps on API call volume. Fetching content during builds, preview verifications, and production validation can exhaust limits faster than anticipated. With microCMS, selecting an appropriate tier and effectively utilizing CDN caching keeps API invocation costs under control.
Conclusion
Migrating to Jamstack and microCMS is currently one of the most rational website development approaches available, delivering improvements across page speed, security, and operational expenses. It is well worth evaluating if your team is fatigued by WordPress maintenance or if sluggish page load speeds are holding back your SEO.
The key to success lies in designing a phased migration and accurately identifying which components can and cannot be made static. Rather than attempting to replace everything at once, making architectural choices that maximize the benefits of the new stack while minimizing risk determines whether the project succeeds.
At GleamHub, we support the development and redesign of corporate websites and media platforms utilizing Jamstack. If you are considering redesigning your company website or migrating away from WordPress, please feel free to reach out.
