In the past month and a half, I’ve made a series of adjustments to my blog, covering areas such as the publishing mechanism, code architecture, and layout design. These changes have not only enhanced the performance and user experience of the blog but also made content maintenance and updates more efficient. This article provides a brief overview of the key changes.
Architecture Migration: From Host + CDN to Serverless
Background of the Migration
Three years ago, as the blog’s traffic grew, I upgraded the architecture from a single cloud server to a Host + CDN model. However, this setup had a significant pain point: every time a page was updated, I had to manually refresh the corresponding CDN cache (since the service provider didn’t offer an API). This seemingly simple task greatly impacted my enthusiasm for making continuous improvements to the blog.
Moving to Serverless
After discovering that my cloud provider had launched EdgeOne Pages (similar to Cloudflare Pages), I decided to migrate the blog to a Serverless architecture, even though the service was still in the testing phase. This cloud computing model allows developers to focus on coding while offloading server management to the cloud provider.
The biggest benefit after the migration was a significant reduction in deployment stress — I just needed to submit code on GitHub, and I could see the deployment effects shortly. This convenience sparked my interest in further optimizing the blog.
Local Build Strategy
Given that the blog has many articles and uses multiple custom remark plugins, the resource demands for each build had exceeded the cloud build limits. Therefore, I adopted a local build strategy, where I build the content locally and submit the built products. To meet the needs of two sites (including the backup site on Github.io), I placed the build content in the docs directory and configured the output directories for both Github and EdgeOne Pages accordingly.
The reason for using the
docsdirectory is that it is the only non-root directory configuration supported by Github Pages.
Implementing 301 Redirects with Serverless Functions
In the last revision, I unified the URL case conventions for articles. To maintain search engine index continuity, I implemented 301 redirects using Nginx mapping. After migrating to Serverless, I lost the ability to configure Nginx, and since EdgeOne Pages only supports 30 redirect rules, I switched to using Serverless Functions for this task:
export function onRequest({request}) {
const targetUrl = request.url;
const post = targetUrl.split('/posts/')[1];
const postId = post.includes('/') ? post.split('/')[0] : post.split('?')[0];
const postIdLower = postId.toLowerCase();
return Response.redirect(`/zh/posts/${postIdLower}/`, 301);
}This method moves the transformation logic to the client-side, making it more efficient than the previous server-side conversion.
Existing Challenges
Since EdgeOne Pages is still in the testing phase, there are some feature limitations, such as the lack of traffic logs and no support for HTTP2. The most frustrating issue right now is that occasionally, some pages fail to deploy (even though the deployment log shows success, the page returns a 404 when accessed). Fortunately, the provider’s engineering team has been responsive, and I believe these issues will be resolved soon.
Performance Improvements: Upgrading to Astro 5
After upgrading from Astro 4.5 to Astro 5, the build performance has significantly improved, mainly due to two factors:
- Major upgrades to the Content Layer in Astro 5:
- 5x faster build times for Markdown pages
- 2x faster build times for MDX pages
- 25-50% reduction in memory usage
- Integration of Vite 6, further optimizing compilation efficiency
With these improvements, the overall site build time has been reduced from 4.5 minutes to just 50 seconds.
Code Optimization and Layout Improvements
This optimization also included modularizing the code and implementing lazy loading for better performance. The layout adjustments, done in collaboration with AI, mainly focused on micro-level changes like font size, letter spacing, and line height. These subtle optimizations gave me a deeper understanding of layout design, and these experiences will also be beneficial for future iOS app development.
Short Domain Service
I set up my own short domain service based on Shlink using an idle cloud server, replacing the previous t.ly service. There are several key points to note during the deployment process:
- Shlink’s built-in web service (RoadRunner) does not support HTTPS and needs to be used in conjunction with Nginx.
- Additional 301 redirects need to be handled at the Nginx layer (even though 301 is set in Shlink, it still returns 302).
- Even though the short domain service doesn’t require content caching, it’s still advisable to deploy a CDN as an extra layer of security.
AI-Assisted Development Experience
Compared to the initial surprise of using AI tools during blog development, AI tools have matured significantly over the past year:
- AI support for front-end development is clearly better than for Apple ecosystem development.
- Various AI development tools (VSCode, Cursor, Trae) have converged in terms of capabilities, with the main differences being in finer details like auto-suggestions.
- Multimodal AI has greatly improved the UI development process, providing more accurate and instant feedback.
- Rather than seeing AI as an automation tool, I prefer to view it as a companion in my learning journey. Writing code by hand, instead of simply copying, helps maintain my technical sharpness and allows me to find the unique value of human collaboration with AI.
Conclusion
This blog optimization has not only improved system performance and user experience but has also led to new breakthroughs in my technical knowledge. As an Apple ecosystem developer, optimizing my personal blog system has allowed me to learn across domains and broaden my vision, providing an excellent opportunity for technical practice.