BetterLink Logo 比邻
切换语言
切换主题

我用Astro 5重构了博客,Lighthouse跑分从68到100

Astro 5 Lighthouse性能优化

上周我做了一件事——把用了两年的 Next.js 博客整个推翻重来,换成了 Astro 5。 说起来挺冲动的。起因是我在 Lighthouse 跑了个分,看到那个刺眼的 68 分,整个人都不好了。我这博客加载慢到什么程度呢?有次朋友说想看我写的文章,链接发过去,他说”转了半天才出来”,我当场社死。 迁移完成后,构建时间从 2 分钟降到 18 秒,性能分从 68 涨到 98。这个结果连我自己都没想到。 这篇文章聊三件事:Astro 为什么这么快、怎么用它搭博客、SEO 该怎么配。如果你也被博客性能折磨过,往下看应该能帮到你。

为什么 Astro 值得你关注

老实讲,我一开始对 Astro 没太大兴趣。市面上框架太多了,Next.js、Nuxt、Gatsby 选得人眼花缭乱。我当时想的是:又要学新东西,时间投入真的值得吗? 直到我看到一组数据—— State of JavaScript 2024 的调查显示,Astro 在兴趣度、留存率、满意度这三项上都拿了第一。使用率排第二,仅次于 Next.js。GitHub Octoverse 2025 更夸张,说 Astro 是增长第三快的语言。 还有个数据挺有意思:60% 的 Astro 站点能通过 Core Web Vitals 的评估,而 WordPress 和 Gatsby 只有 38%。这差距有点大了。 再看看谁在用 Astro:GitHub 的文档站、Firebase 的开发者文档、Smashing Magazine(这家从 WordPress 迁过来的)。2025 年 Google、Reuters、Typst 也开始用了。 这时候我才认真想了想:我的博客是什么?就是一堆 Markdown 文章,加点代码高亮,偶尔有个评论组件。需要 Next.js 那套复杂的全栈能力吗?好像不需要。 所以我的理解是这样的:如果你主要写博客、做文档站、搞营销页,Astro 几乎是目前最优解。但如果你要做电商、SaaS 这种交互很复杂的应用,Next.js 还是更合适。 不是谁更好的问题,是场景不同。

Island 架构——Astro 快的秘密

你有没有遇到过这种情况:页面内容早就出来了,但按钮怎么点都没反应? 这通常是 JavaScript 水合(hydration)在搞鬼。传统框架会把整个页面的 JS 一股脑发给浏览器,然后让它慢慢”激活”。页面越复杂,等得越久。 Astro 的做法完全不同。它用了一个叫 Island 架构(Islands Architecture)的东西。 这玩意儿怎么理解呢?想象你的页面是一片静态 HTML 的海洋,只有那些真正需要交互的组件——比如计数器、表单、评论区——才会”浮出水面”,成为一个个独立的小岛。每个岛自己管自己的 JavaScript,互不干扰。 代码上看起来是这样的:

---
// 这个组件只有滚动到可见区域时才会加载 JS
---
<Counter client:visible />
// 这个组件永远是纯静态 HTML,不加载任何 JS
<Header />

看到 client:visible 了吗?这是 Astro 的指令,告诉它”这个组件只在用户看到它的时候才激活”。还有 client:load(页面加载就激活)、client:idle(浏览器空闲时激活)这些选项。 实际效果呢?我的博客首屏渲染时间(FCP)从 2.1 秒降到 0.8 秒,可交互时间(TTI)从 4.5 秒降到 1.2 秒。包体积?原来 280KB 的 JS,现在只剩 45KB。 这里得说句公道话,如果你的页面全是交互组件,Astro 可能不是最佳选择。它的优势就是”大部分内容是静态的”这个场景。但对于博客、文档这类内容站点,简直是降维打击。

Server Islands——Astro 5 的新玩具

Astro 5 还加了个叫 Server Islands 的特性,挺有意思的。 以前有个问题:如果页面大部分是静态的,但有一小块需要动态内容(比如用户头像、购物车数量),怎么办?要么整页动态渲染,要么就放弃个性化。 Server Islands 的思路是:先给用户一个静态的 HTML 外壳,然后动态的部分让服务器单独注入。 官方的说法是”性能和个性化不再互斥”。我试了一下,确实挺丝滑的。

Content Layer——管理内容的新方式

当你的博客文章超过 100 篇时,一个问题会越来越明显:内容管理变得很乱。 传统方式是在 src/content 目录下堆 Markdown 文件,靠文件系统来组织。文章少的时候还行,多了就头疼——找文件费劲,想接个 CMS 也不方便。 Astro 5 的 Content Layer 彻底改变了这个局面。 它的核心是一个叫 Loader 的机制。你可以从任何地方加载内容:本地 Markdown、Strapi、Contentful、Notion,甚至是自己写的 API。数据来源统一了,管理起来就清爽多了。

// astro.config.mjs
import { defineCollection, z } from 'astro:content';
const blog = defineCollection({
  loader: glob({ pattern: "**/*.md", base: "./src/content/blog" }),
  schema: z.object({
    title: z.string(),
    pubDate: z.date(),
    tags: z.array(z.string()),
  }),
});

这段配置的意思是:从 ./src/content/blog 目录加载所有 Markdown 文件,每篇文章必须有 title、pubDate、tags 这几个字段。 性能提升方面,官方说 Markdown 构建速度最高能快 5 倍,MDX 快 2 倍,内存占用减少 25-50%。我自己的博客测下来,构建时间从 2 分钟降到 18 秒,应该就是这个功劳。 我目前用的是 glob loader 加载本地 Markdown。后面打算试试接 Notion,把写作和发布分开。

View Transitions——丝滑的页面切换

这部分相对简单,快速过一下。 Astro 5 把原来的 ViewTransitions 组件改名成了 ClientRouter,功能一样,就是名字更准确地表达了它的作用——客户端路由。

---
import { ClientRouter } from 'astro:transitions';
---
<html>
  <head>
    <ClientRouter />
  </head>
  <body>
    <!-- 你的内容 -->
  </body>
</html>

加上这个组件后,页面切换就会有过渡动画,而不是生硬地跳转。用户体验提升挺明显的。 2025 年原生 View Transitions API 已经被几乎所有现代浏览器支持了,Firefox 是最后一个。ClientRouter 会自动为不支持的浏览器提供降级方案。 如果你的页面需要跨页面共享状态(比如音乐播放器切页不中断),用 ClientRouter 准没错。如果只是想要简单的过渡动画,原生 CSS View Transitions 也够用了。

SEO 优化实战配置

这部分是重头戏。很多人觉得 Astro 性能好就完事了,其实 SEO 配置也很重要。搜索引擎不只看速度,还看你的页面结构清不清晰、元数据准不准确。 我第一次配 SEO 的时候踩了不少坑,这里分享一下正确的姿势。

Sitemap 配置

先说 sitemap,这个最基础也最容易忘。

npx astro add sitemap

然后在 astro.config.mjs 里加上你的网站地址:

import { defineConfig } from 'astro/config';
import sitemap from '@astrojs/sitemap';
export default defineConfig({
  site: 'https://yourdomain.com', // 别忘了这行!
  integrations: [sitemap()],
});

我第一次就是忘了配 site,结果 sitemap 生成出来全是相对路径,Google 根本不认。这个坑踩了好几天才发现。

Meta 标签管理

每篇文章都应该有独立的 title 和 description。我的做法是在 Markdown frontmatter 里统一管理:

---
title: "Astro 5 性能优化指南"
description: "深入解析 Astro 5 的 Island 架构和 Content Layer..."
publishDate: 2025-11-20
ogImage: "/images/astro-5-cover.png"
---

然后在布局组件里读取这些数据:

---
const { title, description, ogImage } = Astro.props.frontmatter;
---
<head>
  <title>{title}</title>
  <meta name="description" content={description} />
  <meta property="og:title" content={title} />
  <meta property="og:description" content={description} />
  <meta property="og:image" content={ogImage} />
  <link rel="canonical" href={Astro.url} />
</head>

canonical URL 很重要,防止同一篇内容被搜索引擎当成重复页面。

结构化数据(JSON-LD)

这个很多人不知道,但对 SEO 帮助挺大的。结构化数据告诉搜索引擎”这是一篇文章”、“作者是谁”、“发布时间是什么”。

<script type="application/ld+json">
  {JSON.stringify({
    "@context": "https://schema.org",
    "@type": "BlogPosting",
    "headline": title,
    "datePublished": publishDate,
    "author": {
      "@type": "Person",
      "name": "你的名字"
    }
  })}
</script>

可以用 Schema.org Validator 检查你的结构化数据有没有问题。

2025 年 SEO 趋势

这里补充几个今年比较重要的变化:

  1. LLM 也在抓取你的页面。搜索引擎和 AI 都依赖结构化内容,写清楚比堆关键词重要。
  2. 内部链接很重要。每个页面至少要有 3 个内部链接,不然搜索引擎可能觉得它不值得收录。
  3. E-E-A-T 原则。经验、专业、权威、可信——这不是玄学,是 Google 真实的排名因素。

SEO 检查清单

最后给个清单,配置完对着检查一遍:

  • sitemap.xml 已生成且可访问
  • 每个页面有唯一的 title 和 description
  • 图片都有 alt 属性
  • 添加了 JSON-LD 结构化数据
  • robots.txt 配置正确
  • 每个页面有至少 3 个内部链接

图片优化——被低估的性能杀手

图片优化听起来简单,但这里有个坑:很多人以为压缩一下就完事了,其实远不止这些。 Astro 内置了 astro:assets 模块,里面的 Image 组件非常强大:

---
import { Image } from 'astro:assets';
import myImage from '../assets/hero.png';
---
<Image
  src={myImage}
  alt="Hero image"
  widths={[400, 800, 1200]}
  format="webp"
/>

这段代码做了几件事:

  1. 自动推断图片宽高,避免布局偏移(CLS)
  2. 生成多个尺寸的图片,浏览器按需加载
  3. 转换成 WebP 格式,体积更小 关键点来了:图片要放在 src 目录,不要放 public src 里的图片会被 Astro 优化,public 里的不会。我之前就是放错了位置,图片体积大得离谱。 还有个技巧:远程图片可以用 inferSize 自动获取尺寸:
<Image
  src="https://example.com/image.jpg"
  alt="Remote image"
  inferSize
/>

效果有多明显?有个叫 AstroEdge 的开源项目做过测试:图片从 4.2MB 压到 0.8MB,减少了 82%。性能分从 79 直接拉到 100。 Astro 5 还加了实验性的图片裁剪功能和 SVG 组件支持,感兴趣可以去看官方文档。

从其他框架迁移的注意事项

如果你是从 Astro 4 或其他框架迁过来,这部分快速看一下。 Astro 5 的主要变更:

  1. ViewTransitions 改名为 ClientRouter
  2. Astro.glob() 废弃了,改用 import.meta.glob()getCollection()
  3. Hybrid 渲染模式合并到 static 输出
  4. 图片服务从 Squoosh 换成了 Sharp
  5. CSRF 保护默认开启 迁移命令很简单:
npx @astrojs/upgrade

这个命令会自动帮你处理大部分兼容性问题。遇到手动改的地方,它也会给提示。 如果是从 Next.js 或 Gatsby 迁移,工作量会大一些。但好消息是 Astro 支持 React 组件,你可以先把页面迁过来,组件慢慢替换。

写在最后

聊了这么多,核心就这几点:

  1. Island 架构让页面默认零 JavaScript,性能天然领先
  2. Content Layer 统一了内容管理,支持任意数据源
  3. SEO 配置其实只需要几步,但每步都很关键
  4. 图片优化是隐藏的性能大杀器,别忽视
  5. View Transitions 让页面切换更丝滑 如果你正在纠结博客用什么框架,我的建议是:花半小时跑一下 Astro 的官方模板,体验一下那个构建速度和 Lighthouse 分数。
npm create astro@latest -- --template blog

这个模板开箱即用,改改配置就能发布。 一些有用的资源:

  • Astro 官方文档(英文,但最全)
  • Astro 中文网(中文翻译) 下一篇我打算写 Astro + Tailwind + MDX 搭建技术博客的实战教程,感兴趣的话可以关注一下。 你的博客用什么框架?有没有被性能问题困扰过?评论区聊聊。

发布于: 2025年11月24日 · 修改于: 2025年12月4日

相关文章