WordPress에서 Astro로: 재구축으로 Lighthouse 100 달성
WordPress에서 Astro로 마이그레이션: Lighthouse 100을 달성한 방법
솔직히 말하겠습니다: 우리의 오래된 WordPress 사이트는 부끄러웠습니다. 보기에 나빴기 때문이 아닙니다. 실제로는 꽤 괜찮아 보였습니다. 하지만 내부 구조는 어떨까요? 3.2초의 Time to Interactive, 58 정도에 맴도는 Lighthouse 성능 점수, 그리고 매번 배포할 때마다 폭탄을 해제하는 기분이 드는 플러그인 스택이었습니다. 우리는 웹 개발 에이전시입니다. 클라이언트를 위해 빠른 사이트를 구축합니다. 그리고 우리 자신의 사이트는... 빠르지 않았습니다.
그래서 우리는 그것을 완전히 없애고 Astro로 다시 구축했습니다. 결과: Lighthouse의 4가지 카테고리 모두에서 완벽한 100점 — 성능, 접근성, 모범 사례, 그리고 SEO. 단일 페이지가 아닙니다. 모든 페이지에서 말입니다. 이것이 우리가 어떻게 거기에 도달했는지, 그 과정에서 무엇이 깨졌는지, 그리고 우리가 무엇을 다르게 할 것인지에 대한 이야기입니다.
목차
- WordPress를 떠난 이유
- Astro를 선택한 이유
- 마이그레이션 전략
- 차이를 만든 아키텍처 결정
- 성능 최적화 깊이 있는 분석
- Lighthouse 100 점수표
- 전후 비교: 수치
- 우리가 실수한 것들
- 자신의 마이그레이션을 위한 교훈
- FAQ
WordPress를 떠난 이유
보세요, WordPress는 웹의 약 43%를 지탱합니다. 나쁜 플랫폼은 아닙니다. 우리는 클라이언트를 위해 많은 WordPress 사이트를 구축했고 적절할 때는 계속 그럴 것입니다. 하지만 우리의 에이전시 사이트 — 거의 정적인 마케팅 사이트와 블로그 — 에서는 WordPress가 최악의 방식으로 과했습니다.
우리의 WordPress 설정이 어떻게 생겼는지 보세요:
- 테마: Sage (Roots.io)에 기반한 커스텀 테마
- 플러그인: Yoast SEO, WP Rocket, Advanced Custom Fields Pro, Gravity Forms 및 기타 여러 플러그인을 포함한 14개의 활성 플러그인
- 호스팅: WP Engine Professional 플랜 월 $60
- CDN: Cloudflare Pro 월 $20
- 빌드 복잡성: PHP 템플릿팅, 자산용 Webpack, MySQL 데이터베이스
WP Rocket이 적극적인 캐싱을 하고 있었음에도 불구하고 우리의 Core Web Vitals는 평범했습니다. Largest Contentful Paint (LCP)는 모바일에서 2.4초였습니다. Cumulative Layout Shift (CLS)는 0.12였습니다 — 끔찍하지는 않지만 좋지도 않습니다. 플러그인을 업데이트할 때마다 무언가가 깨질 가능성이 0이 아니었습니다.
정말 꼴사나운 점은 무엇입니까? 월에 3,000회 정도의 방문을 받는 사이트를 위해 우리는 매달 $80의 호스팅 비용을 지불하고 있었습니다. 그것은 많은 트래픽이 아니며, 기본적으로 블로그가 있는 브로셔 사이트에 대해서는 많은 비용입니다.
결정의 순간
최종적인 실마리는 2025년 1월에 왔습니다. WordPress 코어 업데이트가 우리의 커스텀 Gutenberg 블록을 깨뜨렸습니다. 이를 수정하려면 ACF Pro를 업데이트해야 했고, 이는 우리의 테마의 PHP 버전 호환성을 업데이트해야 했고, 이는 호스팅 환경을 업데이트해야 했습니다. 일상적인 업데이트여야 할 것이 하루를 꼬박 일하게 했습니다.
저는 팀을 보고 말했습니다. "우리는 클라이언트에게 헤드리스로 가라고 합니다. 우리 자신이 우리의 요리를 먹지 않는 이유는 무엇입니까?"
Astro를 선택한 이유
우리는 재구축을 위해 4가지 옵션을 평가했습니다:
| 프레임워크 | 장점 | 단점 | 우리의 판단 |
|---|---|---|---|
| Next.js | 잘 알고 있음, 훌륭한 에코시스템 | 콘텐츠 사이트에는 과도함, 서버 또는 엣지 런타임 필요 | 너무 무거움 |
| Astro | 콘텐츠 중심, 기본적으로 0 JS 제공, 아일랜드 아키텍처 | 더 작은 에코시스템, 더 새로움 | 완벽한 적합 |
| Eleventy | 단순함, 빠른 빌드, 성숙함 | 제한된 컴포넌트 모델, 덜 현대적인 DX | 2순위 |
| Hugo | 매우 빠른 빌드, 단일 바이너리 | Go 템플릿팅이 고통스러움, 제한된 유연성 | 우리에게 맞지 않음 |
우리는 클라이언트를 위해 많은 Next.js 프로젝트를 구축하고 있으며, 동적 기능이 있는 모든 것에 대한 우리의 표준 도구입니다. 하지만 콘텐츠가 많은 마케팅 사이트의 경우는 어떨까요? Next.js는 필요하든 필요하지 않든 JavaScript 런타임을 제공합니다. 정적 내보내기를 사용하더라도 React를 브라우저로 전송합니다.
Astro의 철학이 우리와 공감했습니다: HTML을 제공하고 필요한 곳에만 JavaScript를 추가합니다. 그들의 아일랜드 아키텍처는 완전히 상호작용하는 React 컴포넌트가 완전히 정적인 HTML 옆에 앉을 수 있으며, 정적인 부분은 JavaScript를 제공하지 않습니다. 이것이 정확히 우리가 필요한 것입니다.
우리는 또한 2024년 내내 클라이언트를 위해 더 많은 Astro 개발 작업을 했으므로 팀은 프레임워크에 익숙했습니다. 학습 연습이 아니었습니다 — 우리가 이미 신뢰하는 도구였습니다.
콘텐츠 레이어 질문
우리가 초반에 한 결정: 우리는 자신의 사이트를 위해 헤드리스 CMS를 사용하지 않을 것입니다. 클라이언트 프로젝트의 경우, 우리는 종종 헤드리스 CMS 설정을 Contentful, Sanity 또는 Storyblok으로 권장합니다. 하지만 모든 작가가 Markdown과 Git에 익숙한 개발자인 우리의 블로그의 경우, Astro의 Content Collections과 리포지토리에 커밋된 MDX 파일이 더 간단하고 빠릅니다.
빌드 시간에 API 호출이 없습니다. 콘텐츠에 대한 콘텐츠 전달 네트워크가 없습니다. 관리하거나 비용을 지불할 추가 서비스가 없습니다. 폴더에 있는 파일일 뿐입니다.
마이그레이션 전략
우리는 빅뱅 마이그레이션을 하지 않았습니다. 이것이 우리의 단계적 접근 방식입니다:
1단계: 콘텐츠 감사 (1주)
우리는 wp-cli를 사용하여 모든 WordPress 콘텐츠를 내보냈고 turndown (HTML-to-Markdown 컨버터)으로 구축된 커스텀 스크립트와 정규식 정리를 사용하여 게시물을 MDX로 변환했습니다. 당시 47개의 블로그 게시물이 있었습니다. 그 중 약 12개는 오래되었거나 성과가 낮아서 관련 있는 새로운 콘텐츠로 리디렉션했고 마이그레이션하지 않았습니다.
2단계: Astro에서 디자인 시스템 (2주)
우리는 우리의 컴포넌트 라이브러리를 Astro 컴포넌트로 재구축했습니다. 버튼, 카드, 섹션 레이아웃, 내비게이션 — 모두 .astro 파일로. 그 중 어느 것도 프레임워크가 필요하지 않습니다. 순수 HTML과 범위가 지정된 스타일의 CSS입니다.
3단계: 페이지 구축 (2주) 홈 페이지, 기능 페이지, 정보, 연락처, 블로그 목록, 개별 블로그 게시물, 404. 우리는 우리의 컴포넌트 라이브러리와 함께 모두 Astro 페이지로 구축했습니다.
4단계: 성능 튜닝 (1주) 이것이 Lighthouse 100 작업이 정말 일어난 곳입니다. 아래에서 더 보겠습니다.
5단계: 시작 및 리디렉션 (2일) 우리는 모든 오래된 URL에 대해 적절한 301 리디렉션을 설정했고, Screaming Frog로 아무것도 깨지지 않았음을 확인했으며, 새 사이트맵을 Google Search Console에 제출했고, DNS를 뒤집었습니다.
총 타임라인: 클라이언트 프로젝트 옆에서 약 6주간의 파트타임 작업입니다.
차이를 만든 아키텍처 결정
기본적으로 JavaScript 없음
우리의 전체 사이트는 약 2KB의 JavaScript를 제공합니다. 이것은 오타가 아닙니다. 2킬로바이트입니다. 그리고 대부분은 모바일 네비게이션 토글과 분석을 위한 작은 스크립트입니다.
여기가 우리의 모바일 내비게이션입니다 — 프레임워크 없음, 의존성 없음:
---
// MobileNav.astro
---
<button id="menu-toggle" aria-expanded="false" aria-controls="mobile-menu">
<span class="sr-only">메뉴 토글</span>
<svg><!-- 햄버거 아이콘 --></svg>
</button>
<nav id="mobile-menu" hidden>
<slot />
</nav>
<script>
const toggle = document.getElementById('menu-toggle');
const menu = document.getElementById('mobile-menu');
toggle?.addEventListener('click', () => {
const expanded = toggle.getAttribute('aria-expanded') === 'true';
toggle.setAttribute('aria-expanded', String(!expanded));
menu?.toggleAttribute('hidden');
});
</script>
Astro 컴포넌트의 <script> 태그는 자동으로 번들링되고 중복 제거됩니다. 작고, 순수한 JavaScript이며, 어디서나 작동합니다.
CSS 전략: 범위가 지정된 스타일 + 최소한의 전역 계층
우리는 Astro의 내장 범위 지정 CSS를 컴포넌트 수준의 스타일에 사용했고, 단일 전역 스타일시트 (축소된 약 8KB)를 타이포그래피, 리셋, 커스텀 속성 및 유틸리티 클래스에 사용했습니다. Tailwind 없습니다. 논쟁이 많은 관점입니다, 알고 있습니다.
우리는 더 큰 애플리케이션과 클라이언트 프로젝트를 위해 Tailwind를 좋아합니다. 하지만 이 정도의 작은 사이트의 경우, 우리가 필요하지 않은 빌드 복잡성과 파일 크기를 추가했습니다. 우리의 수작업으로 작성된 CSS는 정화를 사용하더라도 Tailwind의 출력보다 작습니다.
/* 전역 커스텀 속성 */
:root {
--color-text: #1a1a2e;
--color-bg: #ffffff;
--color-accent: #e94560;
--color-accent-dark: #c81e45;
--font-body: 'Inter', system-ui, sans-serif;
--font-heading: 'Cal Sans', var(--font-body);
--max-width: 72rem;
--space-unit: 0.25rem;
}
스마트 사전로딩을 통한 정적 생성
모든 페이지는 빌드 시간에 정적으로 생성됩니다. 우리는 Astro의 내장 prefetch 통합을 사용하여 호버 시 링크를 미리로드하므로 네비게이션이 즉시 느껴집니다:
// astro.config.mjs
import { defineConfig } from 'astro/config';
import mdx from '@astrojs/mdx';
import sitemap from '@astrojs/sitemap';
export default defineConfig({
site: 'https://socialanimal.dev',
integrations: [mdx(), sitemap()],
prefetch: {
prefetchAll: false,
defaultStrategy: 'hover',
},
build: {
inlineStylesheets: 'auto',
},
});
성능 최적화 깊이 있는 분석
Lighthouse 100에 도달하는 것은 단순히 올바른 프레임워크를 선택하는 것만은 아닙니다. Astro는 좋은 출발점을 제공하지만 마지막 10-15점은 의도적인 노력이 필요합니다. 우리가 한 것은 다음과 같습니다.
이미지 최적화
Astro의 내장 <Image /> 컴포넌트는 자동 형식 변환 (WebP/AVIF), 지연 로딩 및 CLS를 방지하기 위한 적절한 width/height 속성이 포함된 반응형 이미지를 처리합니다.
---
import { Image } from 'astro:assets';
import heroImage from '../assets/hero.jpg';
---
<Image
src={heroImage}
alt="Social Animal 개발팀이 헤드리스 아키텍처에서 작업 중"
widths={[400, 800, 1200]}
sizes="(max-width: 600px) 400px, (max-width: 900px) 800px, 1200px"
format="avif"
fallbackFormat="webp"
quality={80}
loading="eager"
/>
히어로 이미지의 경우, 폴드 위에 있으므로 loading="eager"를 사용합니다. 다른 모든 것은 기본적으로 loading="lazy"를 얻습니다.
우리는 또한 사이트의 모든 이미지를 살펴봤고 다음과 같이 물었습니다: "이것이 정말 이미지여야 합니까?" 여러 장식 요소는 대신 CSS 그래디언트 또는 SVG가 되었습니다. 예를 들어 우리의 히어로 섹션 배경은 미세한 노이즈 텍스처가 작은 인라인 SVG를 통해 적용된 CSS 그래디언트입니다.
폰트 로딩 전략
폰트는 Lighthouse 살인자입니다. 우리의 접근 방식은 다음과 같습니다:
모든 것을 자체 호스트합니다. Google Fonts CDN 없음. 우리는 Inter와 Cal Sans를 다운로드하여 우리의 자신의 도메인에서 제공합니다. 이것은 fonts.googleapis.com에 대한 DNS 조회, TCP 연결 및 TLS 핸드셰이크를 제거합니다.
공격적으로 부분집합 처리합니다. 우리는
glyphhanger를 사용하여 실제로 사용하는 문자를 분석한 다음pyftsubset으로 폰트를 부분집합 처리했습니다. 우리의 Inter Regular WOFF2는 96KB에서 18KB로 줄어들었습니다.메트릭과 밀접하게 일치하는 신중하게 선택된 시스템 폰트 폴백과 함께
font-display: swap을 사용하여 스왑 중 레이아웃 시프트를 최소화합니다.중요한 폰트 파일을 미리로드합니다:
<link rel="preload" href="/fonts/inter-latin-400.woff2" as="font" type="font/woff2" crossorigin />
<link rel="preload" href="/fonts/cal-sans-latin-600.woff2" as="font" type="font/woff2" crossorigin />
호스팅: Cloudflare Pages
우리는 WP Engine ($60/월)에서 Cloudflare Pages (무료 요금제)로 이동했습니다. 네, 무료입니다. 우리의 사이트는 Cloudflare의 무료 플랜의 제한 범위 내에 있습니다 — 월 500 빌드, 무제한 대역폭, 무제한 요청.
Cloudflare Pages는 Git 푸시에서 배포하고, 글로벌 엣지 네트워크에서 제공하며, 캐시 헤더를 자동으로 처리합니다. 우리의 전체 사이트에 대한 빌드 시간은 평균 22초입니다. WordPress 설정과 비교하면 캐시 제거만 해도 더 오래 걸릴 수 있습니다.
월간 호스팅 비용은 $80에서 $0로 이동했습니다.
중요 CSS 인라인화
Astro는 build.inlineStylesheets: 'auto'를 설정할 때 작은 스타일시트를 자동으로 인라인화합니다. 우리의 페이지의 경우, 모든 중요한 스타일은 <head>에 인라인화되므로 0개의 렌더링 차단 CSS 요청이 있습니다. 브라우저는 즉시 페인팅을 시작할 수 있습니다.
제3자 스크립트 규율
이것이 대부분의 사이트가 완벽한 점수를 잃는 곳입니다. 모든 제3자 스크립트는 잠재적인 성능 재앙입니다. 우리는 우리의 것을 무자비하게 제한했습니다:
- 분석: Google Analytics (JavaScript 70KB+ 이상)에서 Plausible Analytics (< 1KB 스크립트, 비동기 로드)로 전환했습니다. 우리는 Plausible에 월 $9를 지불하고, 우리의 필요를 위해 데이터 품질이 사실상 더 낫습니다.
- 폼: 우리의 /contact에서의 연락처 양식은 간단한 HTML 양식과 Cloudflare Pages Functions를 통한 서버측 처리를 사용합니다. JavaScript 양식 라이브러리가 없습니다.
- 채팅 위젯 없음. 소셜 미디어 임베드 없음. 쿠키 동의 배너 없음 (우리는 동의가 필요한 쿠키를 사용하지 않습니다).
Lighthouse 100 점수표
다음은 스로틀 연결에서 Chrome DevTools를 사용하여 측정된 2025년 5월 현재 우리의 실제 Lighthouse 점수입니다 (Lighthouse 기본 모바일 시뮬레이션):
| 메트릭 | 점수 |
|---|---|
| 성능 | 100 |
| 접근성 | 100 |
| 모범 사례 | 100 |
| SEO | 100 |
| First Contentful Paint | 0.6s |
| Largest Contentful Paint | 0.8s |
| Total Blocking Time | 0ms |
| Cumulative Layout Shift | 0 |
| Speed Index | 0.8s |
0ms의 Total Blocking Time이 제 가장 좋아하는 통계입니다. 0입니다. 본질적으로 메인 스레드를 차단하는 JavaScript가 없습니다. 절대 없습니다.
전후 비교: 수치
| 메트릭 | WordPress (전) | Astro (후) | 개선 |
|---|---|---|---|
| Lighthouse 성능 | 58 | 100 | +72% |
| LCP (모바일) | 2.4s | 0.8s | 3배 빠름 |
| CLS | 0.12 | 0 | 제거됨 |
| TBT | 380ms | 0ms | 제거됨 |
| 페이지 무게 (홈) | 1.8MB | 142KB | 92% 더 작음 |
| HTTP 요청 | 47 | 6 | 87% 감소 |
| 제공된 JavaScript | 340KB | 2KB | 99.4% 감소 |
| 월간 호스팅 비용 | $80 | $9 (Plausible만) | 89% 저렴 |
| 빌드/배포 시간 | 3-5 분 | 22 초 | ~10배 빠름 |
| Time to first byte | 420ms | 18ms | 23배 빠름 |
페이지 무게 감소는 우리에게도 어마어마합니다. 1.8MB에서 142KB로. jQuery, React, WP Rocket의 스크립트 로더, Yoast의 스키마 마크업 인젝터, 그리고 14개 플러그인의 스타일시트를 제공하지 않을 때 일어나는 것입니다.
우리가 실수한 것들
모든 것이 순탄하지는 않았습니다. 정직한 시간입니다.
실수 1: 우리는 거의 콘텐츠 관리를 과도 공학했습니다
우리의 첫 본능은 블로그를 위해 Sanity를 헤드리스 CMS로 설정하는 것이었습니다. 우리는 스키마 설정과 Sanity Studio를 설정하는 데 2일을 보낸 후 물러서서 "실제로 이것을 누가 사용할 것입니까?"라고 물었습니다. 답변은... 우리였습니다. Developers. VS Code에서 MDX를 작성하는 것에 완벽하게 행복합니다. 우리는 Sanity를 없애고 Astro Content Collections으로 갔습니다. 진행 중인 비용과 복잡성을 절약했습니다.
실수 2: 폰트 부분집합 처리가 특수 문자를 깼습니다
우리의 초기 폰트 부분집합 처리는 너무 적극적이었습니다. 우리는 다시는 사용하지 않을 것이라고 생각한 문자를 제거했고, 그 다음 em dash와 몇 가지 곡선 따옴표가 있는 블로그 게시물을 발표했으며 상자로 렌더링되었습니다. 교훈: 실제 콘텐츠로 부분집합 처리를 테스트하세요, "ABCDEFG"가 아니라.
실수 3: 우리는 OpenGraph 이미지를 잊었습니다
우리는 동적 OG 이미지 없이 시작했습니다. 누군가가 Twitter/X 또는 LinkedIn에서 블로그 게시물을 공유했을 때, 일반 폴백을 보여주었습니다. 우리는 @astrojs/og를 사용하여 OG 이미지 생성 파이프라인을 구축해야 했습니다 (내부적으로 Satori를 사용함). 원래 범위에 있었어야 합니다.
실수 4: 301 리디렉션 맵에 갭이 있었습니다
외부 사이트가 핫링킹하고 있던 Screaming Frog를 사용하여 오래된 URL을 매핑했음에도 불구하고, 우리는 몇 가지 이미지 URL을 놓쳤습니다. 우리는 Cloudflare의 분석에서 시작 후 약 1주일에 이것들을 발견했고 누락된 리디렉션을 추가했습니다. 마이그레이션 후 항상 서버 로그를 확인하세요 — Google Search Console이 모든 것을 포착하지는 않습니다.
자신의 마이그레이션을 위한 교훈
WordPress에서 정적 우선 프레임워크로 이동을 고려 중이시라면, 제가 당신에게 말해드릴 것은 다음과 같습니다:
마이그레이션 전에 감사하세요. 성과가 없는 콘텐츠를 죽입니다. 마이그레이션은 정리할 좋은 기회입니다.
도구를 작업과 일치시킵니다. Astro는 우리에게 완벽했습니다. 우리는 거의 모두 콘텐츠였기 때문입니다. 무거운 상호작용이 필요하면, Next.js 또는 유사한 프레임워크가 더 나은 선택일 수 있습니다.
오래된 아키텍처를 모방하지 마세요. 우리는 Astro에서 우리의 WordPress 설정을 복제하려고 하지 않았습니다. 우리는 처음부터 모든 것을 다시 생각했습니다. 우리는 정말로 양식 플러그인이 필요합니까? 아니요, 서버리스 함수를 가진
<form>요소가 제대로 작동합니다.전에 측정하세요, 후에 측정하세요, 계속 측정하세요. 우리는 GitHub Actions에서 Lighthouse CI 작업을 설정했으며 모든 풀 요청에서 실행됩니다. PR이 점수를 95 아래로 떨어뜨리면 확인이 실패합니다.
마지막 5%를 위한 예산입니다. Lighthouse 85에서 95로 가는 것은 간단합니다. 95에서 100으로 가려면 폰트 부분집합 처리, 중요 CSS 분석, 이미지 형식 최적화 및 제3자 스크립트 감사가 필요합니다. 시간을 계획하세요.
호스팅 비용은 오래된 설정을 부끄럽게 해야 합니다. 정적 파일을 제공하고 여전히 상당한 호스팅 비용을 지불하면, 뭔가 잘못되었습니다. 정적 호스팅은 이제 상품입니다.
프로젝트에 대해 이와 같은 마이그레이션이 어떤 모습일 것 같은지 관심이 있으시다면, 우리의 가격 책정 페이지를 확인하거나 연락주세요. 우리는 이제 여러 클라이언트를 위해 이 마이그레이션 경로를 했으며, 성능 향상은 일관되게 극적입니다.
FAQ
WordPress 사이트를 Astro로 마이그레이션하는 데 얼마나 오래 걸립니까? 우리의 사이트 (블로그 게시물을 포함한 약 50페이지)의 경우 약 6주의 파트타임 작업이 걸렸습니다. 수백 개의 게시물과 복잡한 커스텀 게시물 타입이 있는 더 큰 사이트는 8-12주가 걸릴 수 있습니다. 실제 개발은 보통 콘텐츠 감사와 리디렉션 매핑보다 빠릅니다.
Next.js 대신 Astro로 Lighthouse 100을 얻을 수 있습니까? 가능하지만 훨씬 더 어렵습니다. Next.js는 정적 페이지에도 JavaScript 런타임을 제공합니다 (React hydration 계층). 95-99의 점수는 신중한 최적화로 달성 가능합니다. 하지만 Astro의 기본 JavaScript 없음 접근 방식은 콘텐츠 사이트에서 완벽한 점수를 훨씬 더 달성 가능하게 만듭니다.
Astro 사이트의 연락처 양식 및 검색과 같은 WordPress 기능은 어떻습니까? 연락처 양식은 일반 HTML 양식과 서버리스 함수 백엔드 (Cloudflare Pages Functions, Netlify Functions 등)로 잘 작동합니다. 검색의 경우, 우리는 빌드 시간에 검색 인덱스를 구축하고 JavaScript 5KB만 제공하는 Pagefind를 사용하는 클라이언트측 검색을 사용합니다. 빠르고 오프라인에서 작동합니다.
WordPress에서 Astro로 마이그레이션하는 것이 SEO를 해칩니까? 제대로 처리하면 아닙니다. 우리는 모든 URL에 대해 301 리디렉션을 설정했고, 가능한 경우 URL 구조를 유지했으며, 새 사이트맵을 제출했고, 모든 구조화된 데이터를 유지했습니다. 우리의 오가닉 트래픽은 마이그레이션 후 3개월 동안 실제로 23% 증가했으며, 아마도 개선된 Core Web Vitals 때문입니다.
Astro 사이트에서 댓글과 같은 동적 콘텐츠를 어떻게 처리합니까? 우리는 블로그에 댓글이 없습니다 — WordPress에서는 대부분 스팸이었습니다. 댓글이 필요하면 Giscus (GitHub Discussions 기반) 또는 Hyvor Talk와 같은 서비스가 임베드된 컴포넌트로 잘 작동합니다. 그들은 Astro 아일랜드로 로드되므로 초기 페이지 로드에 영향을 주지 않습니다.
Astro는 대규모 사이트를 위해 프로덕션 준비가 되어 있습니까? 절대적으로. Astro 5.x (2024년 후반 출시)는 성숙하고 안정적입니다. Porsche, Google, Microsoft 및 Netlify와 같은 회사들이 프로덕션에서 사용합니다. 빌드 성능도 잘 확장됩니다 — 올바른 구성으로 수천 개 페이지를 가진 사이트는 1분 이내에 빌드됩니다.
WordPress와 비교하여 진행 중인 유지 관리는 어떤 모습입니까? 극적으로 더 적습니다. 플러그인 업데이트 없음, 데이터베이스 유지 관리 없음, PHP 보안 패치 없음. 우리는 Astro와 종속성을 월 1회 정도 Dependabot PR을 통해 업데이트합니다. 각 업데이트는 검토 및 병합에 약 5분이 걸립니다. WordPress 업데이트 트레드밀과 비교하세요.
Astro 사이트에서 기술적이 아닌 팀 구성원이 여전히 콘텐츠를 편집할 수 있습니까? 우리의 설정 (Git의 MDX 파일)으로, 당신은 Markdown과 기본 Git 워크플로우에 편안해야 합니다. 기술적이 아닌 편집자가 있는 팀의 경우, 우리는 Astro를 Sanity, Contentful 또는 Storyblok과 같은 헤드리스 CMS와 쌍을 이루는 것을 권장합니다. 편집자는 시각적 인터페이스를 얻고, 정적 생성의 모든 성능 이점을 계속 얻습니다.