Astro 5로 블로그를 리팩터링해 Lighthouse 점수를 68점에서 100점으로 올린 경험

Easton editorial illustration: build pipeline conveyor

지난주, 2년 동안 사용하던 Next.js 블로그를 완전히 뒤엎고 Astro 5로 바꿨습니다. 계기는 Lighthouse 점수가 68점에 불과했기 때문입니다. 블로그가 너무 느리게 열려 지인이 “한참 로딩한 뒤에야 보인다”고 말할 정도였습니다. 마이그레이션 후 빌드 시간은 2분에서 18초로 줄었고 성능 점수는 68점에서 98점으로 올랐습니다.

이 글에서는 세 가지를 다룹니다. Astro가 빠른 이유, Astro로 블로그를 만드는 방법, 그리고 SEO 설정 방법입니다. 블로그 성능 문제로 고생한 적이 있다면 아래 내용이 도움이 될 것입니다.

68→98

Lighthouse 성능 점수

Next.js에서 Astro 5로 마이그레이션

2분→18초

빌드 시간

빌드 시간 85% 단축

2.1초→0.8초

첫 콘텐츠 표시 시간 FCP

62% 향상

4.5초→1.2초

상호작용 가능 시간 TTI

73% 향상

280KB→45KB

JS 번들 크기

84% 감소

60%

Core Web Vitals 통과

Astro 사이트, WordPress/Gatsby는 38%

Source: 실제 프로젝트 테스트 데이터

Astro에 주목해야 하는 이유

솔직히 처음에는 Astro에 별다른 관심이 없었습니다. 시중에는 Next.js, Nuxt, Gatsby 등 프레임워크가 너무 많아 무엇을 골라야 할지 혼란스러웠습니다. 또 새로운 것을 배우는 데 시간을 쓸 가치가 정말 있을까 생각했습니다.

그러다 한 가지 데이터를 봤습니다.

State of JavaScript 2024 조사에서 Astro는 관심도, 유지율, 만족도 세 항목 모두 1위를 차지했습니다. 사용률은 Next.js에 이어 2위였습니다. GitHub Octoverse 2025에서는 Astro를 세 번째로 빠르게 성장한 언어라고 소개했습니다.

또 흥미로운 수치가 있습니다. Astro 사이트의 60%가 Core Web Vitals 평가를 통과한 반면 WordPress와 Gatsby는 38%에 그쳤습니다. 꽤 큰 차이입니다.

Astro를 사용하는 곳도 살펴봤습니다. GitHub 문서 사이트, Firebase 개발자 문서, WordPress에서 마이그레이션한 Smashing Magazine이 있습니다. 2025년에는 Google, Reuters, Typst도 Astro를 사용하기 시작했습니다.

그제야 제 블로그를 진지하게 돌아봤습니다. 제 블로그는 Markdown 글 모음에 코드 하이라이트가 있고 가끔 댓글 컴포넌트가 들어가는 정도입니다. Next.js의 복잡한 풀스택 기능이 정말 필요할까요? 그렇지 않았습니다.

제 결론은 이렇습니다. 주로 블로그, 문서 사이트, 마케팅 페이지를 만든다면 Astro는 현재 거의 최적의 선택입니다. 하지만 전자상거래나 SaaS처럼 상호작용이 매우 복잡한 애플리케이션에는 Next.js가 더 적합합니다.

무엇이 더 우수하냐의 문제가 아니라 쓰임새가 다른 것입니다.

Islands 아키텍처—Astro가 빠른 비결

페이지 내용은 이미 표시됐는데 버튼을 눌러도 반응하지 않는 경험이 있나요?

대개 JavaScript 하이드레이션(hydration) 때문입니다. 전통적인 프레임워크는 페이지 전체의 JS를 한꺼번에 브라우저로 보낸 뒤 천천히 “활성화”합니다. 페이지가 복잡할수록 더 오래 기다려야 합니다.

Astro의 방식은 완전히 다릅니다. 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초로 줄었습니다. JS 번들은 기존 280KB에서 45KB만 남았습니다.

물론 페이지 전체가 상호작용형 컴포넌트라면 Astro가 최선이 아닐 수 있습니다. 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초로 줄었는데 아마 Content Layer의 효과일 것입니다.

현재는 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의 Islands 아키텍처와 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 흐름

올해 중요해진 변화도 몇 가지 덧붙이겠습니다.

LLM도 페이지를 수집합니다. 검색 엔진과 AI 모두 구조화된 콘텐츠에 의존하므로 키워드를 나열하는 것보다 명확하게 쓰는 일이 중요합니다.
내부 링크가 중요합니다. 페이지마다 내부 링크가 최소 3개는 있어야 합니다. 그렇지 않으면 검색 엔진이 색인할 가치가 낮다고 판단할 수 있습니다.
E-E-A-T 원칙. 경험, 전문성, 권위성, 신뢰성은 막연한 이야기가 아니라 Google의 실제 순위 요소입니다.

SEO 체크리스트

마지막으로 설정을 마친 뒤 확인할 체크리스트입니다.

sitemap.xml이 생성되어 접근할 수 있음
각 페이지에 고유한 title과 description이 있음
모든 이미지에 alt 속성이 있음
JSON-LD 구조화 데이터가 추가됨
robots.txt가 올바르게 설정됨
각 페이지에 내부 링크가 최소 3개 있음

이미지 최적화—과소평가하기 쉬운 성능의 복병

이미지 최적화는 간단해 보이지만 함정이 있습니다. 많은 사람이 압축만 하면 끝이라고 생각하지만 실제로는 그렇지 않습니다.

Astro에는 강력한 Image 컴포넌트를 제공하는 astro:assets 모듈이 내장되어 있습니다.


---

import { Image } from 'astro:assets';
import myImage from '../assets/hero.png';

---

<Image
  src={myImage}
  alt="Hero image"
  widths={[400, 800, 1200]}
  format="webp"
/>

이 코드는 여러 작업을 수행합니다.

이미지 너비와 높이를 자동 추론해 레이아웃 이동(CLS)을 방지합니다.
여러 크기의 이미지를 생성해 브라우저가 필요에 따라 불러오게 합니다.
더 작은 WebP 형식으로 변환합니다.

핵심은 이미지를 public이 아니라 src 디렉터리에 넣는 것입니다. 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의 주요 변경 사항:

ViewTransitions의 이름이 ClientRouter로 변경됐습니다.
Astro.glob()은 폐기됐으며 import.meta.glob() 또는 getCollection()을 사용해야 합니다.
Hybrid 렌더링 모드가 static 출력에 통합됐습니다.
이미지 서비스가 Squoosh에서 Sharp로 변경됐습니다.
CSRF 보호가 기본으로 활성화됩니다.

마이그레이션 명령은 간단합니다.

npx @astrojs/upgrade

이 명령은 대부분의 호환성 문제를 자동으로 처리합니다. 수동 수정이 필요한 곳도 알려 줍니다.

Next.js 또는 Gatsby에서 마이그레이션한다면 작업량이 더 많을 수 있습니다. 다행히 Astro는 React 컴포넌트를 지원하므로 페이지부터 옮긴 뒤 컴포넌트를 차례로 교체할 수 있습니다.

마무리

지금까지의 핵심을 정리하면 다음과 같습니다.

Islands 아키텍처 덕분에 페이지는 기본적으로 JavaScript가 없어 성능 면에서 유리합니다.
Content Layer는 콘텐츠 관리를 통합하고 모든 데이터 소스를 지원합니다.
SEO 설정에는 몇 단계만 필요하지만 각 단계가 모두 중요합니다.
이미지 최적화는 숨어 있는 강력한 성능 개선 수단이므로 놓치지 마세요.
View Transitions는 페이지 전환을 더 매끄럽게 만듭니다.

블로그 프레임워크를 고민하고 있다면 30분만 투자해 Astro 공식 템플릿을 실행하고 빌드 속도와 Lighthouse 점수를 직접 확인해 보세요.

npm create astro@latest -- --template blog

이 템플릿은 바로 사용할 수 있으며 설정만 조금 바꾸면 게시할 수 있습니다.

유용한 자료:

Astro 공식 문서(영문이지만 가장 자세합니다.)
Astro 중국어 사이트(중국어 번역본)

다음 글에서는 Astro + Tailwind + MDX로 기술 블로그를 만드는 실전 과정을 다룰 예정입니다. 관심이 있다면 지켜봐 주세요.

여러분의 블로그는 어떤 프레임워크를 사용하나요? 성능 문제로 어려움을 겪은 적이 있나요? 댓글로 이야기해 주세요.

Next.js에서 Astro 5로 마이그레이션하는 전체 과정

마이그레이션 준비부터 SEO 설정까지 Lighthouse 성능 점수를 68점에서 98점으로 높이는 전체 단계

Estimated time: PT4H

1

Step 1: Islands 아키텍처와 성능 이점 이해

Islands 아키텍처의 핵심:
2

Step 2: Content Layer로 콘텐츠 관리 설정

Content Layer의 핵심은 Loader 메커니즘입니다.
3

Step 3: SEO 최적화 설정

Sitemap 설정:
4

Step 4: 이미지 성능 최적화

Astro 내장 astro:assets 모듈의 Image 컴포넌트:
5

Step 5: View Transitions 설정

Astro 5에서는 ViewTransitions 컴포넌트의 이름이 ClientRouter로 변경됐습니다. 기능은 같지만 클라이언트 라우팅이라는 역할을 이름에 더 정확히 담았습니다. import { ClientRouter } from ‘astro:transitions’로 가져온 뒤 <head>에 <ClientRouter />를 추가합니다. 그러면 페이지가 갑자기 바뀌는 대신 전환 애니메이션이 적용되어 사용자 경험이 눈에 띄게 좋아집니다. 2025년에는 네이티브 View Transitions API를 거의 모든 최신 브라우저가 지원했으며 Firefox가 마지막으로 합류했습니다. ClientRouter는 지원하지 않는 브라우저에 자동으로 폴백을 제공합니다. 음악 플레이어가 페이지를 이동해도 끊기지 않아야 하는 경우처럼 페이지 간 상태를 공유해야 한다면 ClientRouter가 적합합니다. 단순한 전환 애니메이션만 필요하다면 네이티브 CSS View Transitions로도 충분합니다.
6

Step 6: 다른 프레임워크에서 마이그레이션

Astro 5의 주요 변경 사항: ViewTransitions의 이름이 ClientRouter로 변경됐고, Astro.glob()은 폐기되어 import.meta.glob() 또는 getCollection()을 사용해야 하며, Hybrid 렌더링 모드는 static 출력에 통합됐습니다. 이미지 서비스는 Squoosh에서 Sharp로 변경됐고 CSRF 보호가 기본으로 활성화됩니다. 마이그레이션 명령: npx @astrojs/upgrade(대부분의 호환성 문제를 자동으로 처리하고 수동 수정이 필요한 부분도 알려 줍니다.) Next.js 또는 Gatsby에서 마이그레이션한다면 작업량이 더 많을 수 있지만 Astro는 React 컴포넌트를 지원하므로 페이지부터 옮긴 뒤 컴포넌트를 차례로 교체할 수 있습니다.

FAQ

Next.js에서 Astro 5로 마이그레이션하면 성능이 얼마나 향상되나요? 구체적인 수치는 무엇인가요?

실제 프로젝트 테스트 결과:
• 빌드 시간: 2분에서 18초로 단축(85% 감소)
• Lighthouse 성능 점수: 68점에서 98점으로 상승(44% 향상)
• 첫 콘텐츠 표시 시간(FCP): 2.1초에서 0.8초로 단축(62% 향상)
• 상호작용 가능 시간(TTI): 4.5초에서 1.2초로 단축(73% 향상)
• JS 번들 크기: 280KB에서 45KB로 감소(84% 감소)

State of JavaScript 2024 조사 결과:
• Astro는 관심도, 유지율, 만족도 세 항목에서 모두 1위를 차지했습니다.
• Astro 사이트의 60%가 Core Web Vitals 평가를 통과했지만 WordPress와 Gatsby는 38%에 그쳤습니다.

이 데이터는 특히 콘텐츠 중심 웹사이트에서 Astro가 뚜렷한 성능 우위를 보인다는 사실을 보여 줍니다.

Astro의 Islands 아키텍처란 무엇이며 어떻게 이해하고 사용해야 하나요?

Islands 아키텍처의 핵심:
• 페이지를 정적 HTML의 바다라고 생각하면, 카운터·폼·댓글 영역처럼 실제 상호작용이 필요한 컴포넌트만 수면 위로 떠올라 독립된 섬이 됩니다.
• 각 섬은 자체 JavaScript를 독립적으로 관리합니다.

코드 예시:
• <Counter client:visible /> (컴포넌트가 화면에 보일 때만 JS를 로드합니다.)
• <Header /> (항상 순수 정적 HTML이며 JS를 전혀 로드하지 않습니다.)

Astro 디렉티브:
• client:visible (화면에 보일 때 활성화)
• client:load (페이지가 로드될 때 활성화)
• client:idle (브라우저가 유휴 상태일 때 활성화)

Server Islands(Astro 5의 새로운 기능):
• 먼저 정적 HTML 셸을 사용자에게 제공한 뒤 동적 부분만 서버에서 따로 주입합니다.
• 공식 설명처럼 성능과 개인화가 더 이상 상충하지 않습니다.

페이지 전체가 상호작용형 컴포넌트라면 Astro가 최선이 아닐 수 있습니다. Astro의 강점은 대부분의 콘텐츠가 정적인 환경에 있으며, 블로그나 문서 사이트에서는 압도적인 이점을 제공합니다.

Astro 5의 Content Layer는 어떻게 설정하며 성능은 얼마나 향상되나요?

Content Layer의 핵심은 Loader 메커니즘입니다. 어디서든 콘텐츠를 불러올 수 있습니다.
• 로컬 Markdown, Strapi, Contentful, Notion은 물론 직접 만든 API도 사용할 수 있습니다.
• 데이터 소스를 통합하면 관리가 훨씬 간결해집니다.

설정 예시:
astro.config.mjs에서:
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초로 줄었으며 Content Layer의 효과로 보입니다.

현재는 glob loader로 로컬 Markdown을 불러옵니다. 앞으로 Notion을 연결해 작성과 게시 과정을 분리해 볼 계획입니다.

Astro 5에서 SEO를 어떻게 설정해야 하며 핵심 사항은 무엇인가요?

Sitemap 설정:
• npx astro add sitemap을 실행합니다.
• astro.config.mjs에 site: 'https://yourdomain.com'을 추가합니다. 이 줄을 빠뜨리면 sitemap이 모두 상대 경로로 생성되어 Google이 인식하지 못할 수 있습니다.

Meta 태그 관리:
• 각 글에는 고유한 title과 description이 있어야 합니다.
• Markdown frontmatter에서 title/description/publishDate/ogImage를 통합 관리합니다.
• 레이아웃 컴포넌트에서 이 데이터를 읽어 title/meta/canonical URL을 추가합니다. canonical URL은 같은 콘텐츠가 중복 페이지로 인식되는 일을 막는 데 중요합니다.

JSON-LD 구조화 데이터:
• 검색 엔진에 글 유형, 작성자, 게시 시점을 알려 줍니다.
• 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에는 강력한 Image 컴포넌트를 제공하는 astro:assets 모듈이 내장되어 있습니다.
• 이미지 너비와 높이를 자동 추론해 레이아웃 이동(CLS)을 방지합니다.
• 여러 크기의 이미지를 생성해 브라우저가 필요에 따라 불러옵니다.
• 더 작은 WebP 형식으로 변환합니다.

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

핵심 사항:
• 이미지는 public이 아니라 src 디렉터리에 둬야 합니다.
• 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 5로 마이그레이션할 때 무엇을 주의해야 하나요?

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 컴포넌트를 지원하므로 페이지부터 옮긴 뒤 컴포넌트를 차례로 교체할 수 있습니다.

블로그 프레임워크를 고민하고 있다면 다음과 같이 해 보세요.
• 30분만 투자해 Astro 공식 템플릿을 실행하고 빌드 속도와 Lighthouse 점수를 직접 확인합니다.
• npm create astro@latest -- --template blog
• 이 템플릿은 바로 사용할 수 있으며 설정만 조금 바꾸면 게시할 수 있습니다.

3분 읽기 · 게시일: 2025년 11월 24일 · 수정일: 2026년 9월 8일

Easton

기술

Astro 5로 블로그를 리팩터링해 Lighthouse 점수를 68점에서 100점으로 올린 경험

Astro에 주목해야 하는 이유

Islands 아키텍처—Astro가 빠른 비결

Server Islands—Astro 5의 새로운 기능

Content Layer—새로운 콘텐츠 관리 방식

View Transitions—매끄러운 페이지 전환

SEO 최적화 실전 설정

Sitemap 설정

Meta 태그 관리

구조화 데이터(JSON-LD)

2025년 SEO 흐름

SEO 체크리스트

이미지 최적화—과소평가하기 쉬운 성능의 복병

다른 프레임워크에서 마이그레이션할 때 주의할 점

마무리

Next.js에서 Astro 5로 마이그레이션하는 전체 과정

Step 1: Islands 아키텍처와 성능 이점 이해

Step 2: Content Layer로 콘텐츠 관리 설정

Step 3: SEO 최적화 설정

Step 4: 이미지 성능 최적화

Step 5: View Transitions 설정

Step 6: 다른 프레임워크에서 마이그레이션

FAQ

프론트엔드 프레임워크

React 코드에 지쳤나요? Svelte 5로 코드량은 절반, 성능은 두 배로(완전 튜토리얼)

React 19 폼에 아직도 코드 30줄? Actions로 간소화하고 성능은 40% 향상

Vue 3 + TypeScript 모범 사례: 2025년 엔터프라이즈 프로젝트 아키텍처 가이드

댓글

Astro에 주목해야 하는 이유

Islands 아키텍처—Astro가 빠른 비결

Server Islands—Astro 5의 새로운 기능

Content Layer—새로운 콘텐츠 관리 방식

View Transitions—매끄러운 페이지 전환

SEO 최적화 실전 설정

Sitemap 설정

Meta 태그 관리

구조화 데이터(JSON-LD)

2025년 SEO 흐름

SEO 체크리스트

이미지 최적화—과소평가하기 쉬운 성능의 복병

다른 프레임워크에서 마이그레이션할 때 주의할 점

마무리

Next.js에서 Astro 5로 마이그레이션하는 전체 과정

Step 1: Islands 아키텍처와 성능 이점 이해

Step 2: Content Layer로 콘텐츠 관리 설정

Step 3: SEO 최적화 설정

Step 4: 이미지 성능 최적화

Step 5: View Transitions 설정

Step 6: 다른 프레임워크에서 마이그레이션

FAQ

프론트엔드 프레임워크

React 코드에 지쳤나요? Svelte 5로 코드량은 절반, 성능은 두 배로(완전 튜토리얼)

관련 글

React 19 폼에 아직도 코드 30줄? Actions로 간소화하고 성능은 40% 향상

Vue 3 + TypeScript 모범 사례: 2025년 엔터프라이즈 프로젝트 아키텍처 가이드

댓글