웹사이트를 더 빠르게 만드는 법: 실용적인 체크리스트

웹사이트를 더 빠르게 만들려면 먼저 PageSpeed Insights로 측정한 다음, 그것이 가리키는 가장 큰 원인을 고치세요. 보통은 지나치게 큰 이미지, 과도한 자바스크립트, 무거운 폰트, 또는 서드파티 스크립트입니다. 목표는 구글의 Core Web Vitals "좋음" 기준입니다. 주요 콘텐츠가 2.5초 안에 보이고, 탭에 대한 반응이 200밀리초 안에 나오며, 레이아웃이 거의 튀지 않는 것입니다. 대부분의 사이트는 전면 재작성이 아니라 몇 가지 변경으로 이 기준에 도달합니다.

바꾸기 전에 측정하기

추측은 시간을 낭비합니다. 무료 도구 두 가지면 거의 모든 경우를 다룰 수 있습니다.

• PageSpeed Insights(pagespeed.web.dev) — 실제 URL을 붙여 넣으세요. 실제 Chrome 사용자의 필드 데이터(트래픽이 충분하다면)와 시뮬레이션 로딩의 랩 데이터, 그리고 구체적인 문제 목록을 보여 줍니다.
• Chrome 개발자 도구의 Lighthouse — 열 수 있는 모든 페이지(미리보기 포함)에서 실행하는 같은 랩 테스트입니다. 모바일 모드로 테스트하세요. 문제는 느린 네트워크의 휴대폰에서 드러납니다.

중요한 숫자는 구글의 Core Web Vitals입니다. 2026년 9월 기준, web.dev의 구글 문서는 페이지 로드의 75번째 백분위수로 측정한 다음의 "좋음" 기준을 제시합니다.

INP는 2024년에 이전 지표인 최초 입력 지연(FID)을 대체했습니다. 도구가 여전히 FID를 보고한다면 오래된 것입니다.

시작 수치를 적어 두세요. 각 수정 후에 다시 테스트해서 무엇이 도움이 되었는지 알 수 있게 하세요.

시간이 어디서 새는가: 선택지와 트레이드오프

흔한 원인마다 해결책이 있고, 각 해결책에는 비용이 있습니다. 위쪽에 있는 것부터 시작하세요. 가장 저렴하고 가장 흔한 것들입니다.

이미지

이미지는 가장 흔한 문제이고 가장 고치기 쉽습니다. 4,000픽셀짜리 사진을 800픽셀 너비로 보여 주면, 모든 방문자가 실제로 보는 것의 다섯 배를 내려받게 됩니다.

• 표시되는 크기에 맞게 이미지를 제공하고, 휴대폰과 데스크톱을 위해 반응형 srcset 크기를 쓰세요.
• 최신 형식(WebP 또는 AVIF)과 적절한 압축을 사용하세요.
• 모든 이미지에 width와 height를 설정해서 브라우저가 공간을 미리 잡게 하세요. 이것만으로도 레이아웃 이동 대부분이 해결됩니다.
• 화면 아래의 이미지는 loading="lazy"로 지연 로드하세요.
• 페이지 상단의 주요 이미지는 절대 지연 로드하지 마세요. 구글의 LCP 가이드는 이에 대해 단호합니다. LCP 이미지를 지연 로드하면 항상 LCP가 늦어집니다. 대신 fetchpriority="high"를 주세요.

자바스크립트

AI로 만든 많은 사이트는 싱글 페이지 앱(SPA)입니다. 브라우저가 자바스크립트 번들을 내려받은 다음 페이지를 그립니다. 번들이 클수록 빈 화면이 오래 보입니다. 노력이 적게 드는 순서대로 고치는 방법은 다음과 같습니다.

1. 사용하지 않는 것을 제거하세요. 의존성 목록을 요청해서, 한 번 추가하고 잊힌 라이브러리를 잘라내세요. 날짜 하나를 위한 날짜 라이브러리, 아이콘 다섯 개를 위한 전체 아이콘 팩 같은 것들입니다.
2. 경로별로 나누세요. 관리자 대시보드의 코드는 누군가 그 페이지를 열 때만 로드하고, 홈 페이지에서는 로드하지 마세요.
3. 공개 페이지를 사전 렌더링하세요. 실제 HTML로 제공되는 마케팅 페이지는 자바스크립트가 실행되기 전에 나타납니다. 이는 검색엔진에도 도움이 됩니다. AI로 만든 웹사이트의 SEO를 참고하세요.

INP가 느린 것은 보통 긴 작업 하나가 페이지를 막고 있다는 뜻입니다. 예를 들어 키를 누를 때마다 거대한 목록을 필터링하거나, 셀 하나가 바뀔 때 표 전체를 다시 그리는 경우입니다. Chrome 개발자 도구의 Performance 패널이 어떤 작업인지 보여 줍니다.

폰트

폰트 패밀리와 굵기마다 파일이 하나씩 더 필요합니다. 보통 패밀리 두 개와 굵기 서너 개면 충분합니다. 화면 상단에서 쓰는 폰트는 프리로드하고, 텍스트가 즉시 보이도록 font-display: swap을 쓰세요. 외부 폰트 서비스가 방문자에게 느리다면 폰트를 직접 호스팅하세요.

서드파티 스크립트

채팅 위젯, 분석 도구, 히트맵, 광고 픽셀, 임베드 동영상, 소셜 피드는 모두 다른 서버에서 코드를 가져옵니다. 각각은 작아 보이지만 합치면 종종 페이지에서 가장 느린 부분이 됩니다. 실제로 보는 것만 남기세요. 나머지는 페이지가 상호작용 가능해진 뒤에 로드하고, 무거운 임베드(유튜브 플레이어, 지도)는 가벼운 미리보기로 바꾸고 클릭할 때 실제 것을 로드하세요.

서버 응답

첫 바이트까지의 시간(TTFB), 즉 서버가 응답을 시작하는 데 걸리는 시간은 다른 모든 지표의 밑바닥에 깔려 있습니다. CDN(방문자 가까이에 있는 서버 네트워크, CDN이란 무엇인가 참고)에서 제공되는 정적 페이지는 거의 어디서나 빠릅니다. 요청마다 서버가 만드는 페이지는 그 서버와 데이터베이스에 의존합니다. 반복되는 작업을 캐싱하고, 느린 쿼리에 데이터베이스 인덱스를 추가하는 것이 보통의 해결책입니다.

잘 통하는 프롬프트

구체적으로 쓰세요. 페이지, 지표, 제약을 명시하세요. PageSpeed Insights 결과가 있다면 붙여 넣으세요.

PageSpeed Insights에서 홈 페이지의 모바일 LCP가 4.8초로 나옵니다. LCP 요소는 히어로 이미지입니다. 히어로 이미지를 크기 조정하고 WebP로 변환해 주세요. 반응형 크기를 제공하고, width와 height를 설정하고, fetchpriority="high"를 주고, 지연 로드되지 않도록 해 주세요. 화면 아래의 모든 이미지는 지연 로드해 주세요. 디자인은 바꾸지 마세요.

이 앱의 의존성을 감사해 주세요. 각 패키지, 그것을 사용하는 곳, 번들에 대략 얼마나 더하는지 나열해 주세요. 사용하지 않는 것은 제거하고, /admin과 /settings 경로는 방문할 때만 로드되는 별도 청크로 나눠 주세요.

/products의 검색창이 버벅거립니다. 필터에 디바운스를 적용하고, 키를 누를 때마다 목록 전체를 다시 그리지 않도록 하고, 항목이 200개를 넘으면 목록을 페이지로 나누거나 가상화해 주세요.

단계별로 따라 하기

1. 라이브 페이지를 테스트하세요. 모바일에서 PageSpeed Insights로 측정하세요. LCP, INP, CLS와 나열된 상위 세 가지 문제를 적어 두세요.
2. 이미지부터 고치세요. 크기, 형식, 치수, 화면 아래 지연 로드, 히어로 우선순위.
3. 사용하지 않는 서드파티 스크립트를 줄이고, 나머지는 지연시키세요.
4. 폰트를 디자인에 필요한 만큼으로 줄이세요.
5. 자바스크립트를 줄이세요. 사용하지 않는 패키지를 제거하고, 경로별로 나누세요.
6. 공개 페이지가 아직 클라이언트에서 렌더링되고 LCP가 여전히 느리다면 사전 렌더링하세요.
7. 서버를 확인하세요. 캐싱, 데이터베이스 인덱스, 거의 바뀌지 않는 콘텐츠의 정적 호스팅.
8. 다시 게시하고 재테스트하세요. PageSpeed Insights의 필드 데이터는 실제 방문이 쌓이면서 몇 주에 걸쳐 갱신되므로, 초기 결과는 랩 데이터로 판단하세요.

흔한 실수

• 빠른 노트북에서만 테스트하기. 방문자는 중간 사양의 휴대폰과 불안정한 모바일 데이터를 씁니다. 모바일 모드로 테스트하세요.
• 완벽한 100점을 쫓기. 랩 점수는 지침일 뿐입니다. Core Web Vitals가 좋음 범위에 들어오면, 콘텐츠와 사용성이 마지막 몇 점보다 더 중요합니다.
• 히어로 이미지를 포함해 모든 것을 지연 로드하기. 그러면 LCP가 더 나빠집니다.
• 속도 플러그인이나 라이브러리를 추가로 얹기. 무게를 줄이는 것이 그것을 관리하는 코드를 더하는 것보다 거의 항상 낫습니다.
• 라이브 사이트가 아니라 미리보기를 최적화하기. 개발 미리보기는 최적화되지 않은 빌드로 실행됩니다. 게시된 URL을 측정하세요.
• 속도를 한 번만 고치기. 새 위젯, 이미지, 기능마다 무게가 더해집니다. 큰 변경 후에는 다시 테스트하세요.

속도 체크리스트

• 모바일에서 LCP ≤ 2.5초, INP ≤ 200ms, CLS ≤ 0.1
• 이미지가 크기 조정되고, 압축되고, 최신 형식이며, width와 height가 있음
• 히어로 이미지는 지연 로드하지 않음; 화면 아래 이미지는 지연 로드함
• 사용하지 않는 자바스크립트 라이브러리가 없고, 무거운 경로는 분리됨
• 폰트 패밀리 두 개 이하, 주요 폰트 프리로드
• 실제로 쓰는 서드파티 스크립트만 있고, 늦게 로드됨
• 가능하면 공개 페이지가 사전 렌더링되거나 정적임
• 게시 후 라이브 URL에서 재테스트함

속도와 모바일 레이아웃은 함께 갑니다. 웹사이트를 모바일 반응형으로 만드는 법을 참고하세요. 출시 전 전체 점검은 AI 프로토타입을 프로덕션으로 옮기는 법에서 나머지를 다룹니다.

Mythex에서의 속도

Mythex에서는 채팅으로 요청하거나, Pro에서는 코드 편집기에서 이런 변경을 합니다. Preview는 개발 서버로 실행되므로, Preview가 아니라 게시된 URL을 확인하세요. 정적 프런트엔드는 게시할 때 정적 사이트로 배포되며(정적 웹사이트), 이는 콘텐츠 페이지에 적합합니다. 서버가 있는 앱은 0으로 축소됩니다. 유휴 상태에서는 잠들고 다음 방문 때 깨어나므로, 조용한 기간 뒤의 첫 요청은 더 느리며, 연결된 데이터베이스는 5분간 유휴 상태가 지나면 잠듭니다(호스팅 한도). 공개 페이지가 첫 방문에서만 느리다면 이것이 원인일 가능성이 큽니다. 마케팅 페이지를 정적으로 유지하면 도움이 됩니다. 변경 후에는 다시 게시하고 강력 새로고침하세요.

자주 묻는 질문