지연된 JavaScript 로딩으로 TBT 시간 단축하기

지연된 JavaScript 로딩은 페이지 콘텐츠의 렌더링을 방해하는 JavaScript 파일을 적절한 순서로 연기하여 Total Blocking Time(TBT) 즉, 총 차단 시간을 줄이는 방법입니다. 간단히 말해, 중요하지 않은 스크립트 파일에 defer 또는 async를 추가하여 메인 스레드의 차단을 줄여 사용자가 페이지를 더 빠르게 보도록 하고, 더 일찍 클릭할 수 있게 하며 Core Web Vitals 메트릭을 개선할 수 있습니다. 사이트에 지연된 JavaScript 로딩을 적용하려면 먼저 어떤 파일이 중요한지 식별하고, 종속성이 있는 스크립트에는 일반적으로 defer를 사용하고, 독립적인 제3자 스크립트에는 대부분 async를 사용하는 것이 좋습니다. 이후에는 PageSpeed Insights, Lighthouse 및 Chrome DevTools를 통해 TBT 값을 측정해야 합니다.

현대 웹사이트에서 성능 문제는 종종 이미지가 아닌 제어되지 않은 JavaScript 사용으로 인해 발생합니다. 전자상거래 사이트에서 제품 필터, 라이브 지원, 광고 픽셀, 분석 코드, 댓글 플러그인, A/B 테스트 도구 및 테마 스크립트가 동시에 로드되면 브라우저의 메인 스레드는 오랜 시간 동안 바쁘게 됩니다. 이 문제는 특히 모바일 기기에서 더욱 두드러집니다. 사용자가 화면에서 제목을 보더라도 메뉴를 클릭할 때 반응이 없을 수 있으며, Lighthouse 보고서에서는 Total Blocking Time이 높게 나타날 수 있습니다.

이번 가이드에서는 defer와 async 속성이 무엇을 하는지, 언제 각각을 사용해야 하는지, WordPress 및 맞춤형 소프트웨어 프로젝트에서 어떻게 적용할 수 있는지, 측정 시 주의해야 할 사항 및 실제적인 TBT 개선 사례를 단계별로 다룰 것입니다. Hostragons 인프라에서 호스팅되는 사이트에 대한 권장 사항은 일반 웹 표준에 부합하며, 올바른 호스팅, CDN, SSL 및 캐싱 결정이 JavaScript 최적화를 어떻게 지원하는지도 설명하겠습니다. Hostragons 웹 호스팅 패키지

TBT란 무엇이며 JavaScript와의 관계는?

TBT는 Total Blocking Time의 약자로, 페이지가 사용자 상호작용에 준비되는 것을 지연시키는 메인 스레드 블로킹을 측정합니다. Lighthouse 실험에서 First Contentful Paint와 Time to Interactive 사이에 50 밀리초를 초과하는 긴 작업이 많아지면 TBT 값이 증가합니다. 예를 들어, JavaScript 작업이 180ms 걸린다면, 이 중 처음 50ms 이후의 130ms가 차단 시간에 기여하게 됩니다.

이 메트릭은 사용자 경험 측면에서 매우 중요합니다. 사용자가 페이지가 열린 후 메뉴, 장바구니 추가 버튼 또는 검색 상자에 클릭했을 때 브라우저가 여전히 JavaScript를 실행하고 있다면 상호작용이 지연됩니다. 사용자는 이를 멈춤, 느린 반응 또는 사이트 오류로 인식하게 됩니다. 2026 SEO 기준에서 Google은 페이지 경험을 단일 점수로 줄이지 않지만, 빠르고 안정적인 상호작용을 제공하는 사이트는 사용자 만족도와 전환율 측면에서 이점을 가질 수 있습니다.

높은 TBT 값의 일반적인 징후

• 모바일 PageSpeed Insights 보고서에서 TBT 값이 300ms를 초과함.
• Lighthouse 보고서에서 JavaScript 실행 시간을 줄이거나 메인 스레드 작업을 최소화하라는 경고가 나타남.
• 페이지가 보이지만 메뉴, 슬라이더, 필터 또는 폼 필드가 느리게 반응함.
• 제3자 광고, 라이브 지원 또는 분석 스크립트가 보고서에서 높은 비용으로 나타남.
• 특히 저사양 Android 기기에서 스크롤 및 클릭 지연이 발생함.

좋은 목표로 TBT 값을 200ms 이하로 유지하는 것은 대부분의 콘텐츠 사이트에 건강하게 간주됩니다. 더 복잡한 전자상거래 또는 SaaS 인터페이스에서는 이 목표를 달성하기 위해 단순히 defer와 async만으로는 부족할 수 있습니다. 코드 분할, 불필요한 패키지 제거, 캐싱, 서버 응답 시간 개선 및 중요 CSS 조정이 필요할 수 있습니다. 그럼에도 불구하고 지연된 JavaScript 로딩은 대부분의 프로젝트에서 첫 번째로 적용하고 빠른 결과를 얻을 수 있는 최적화 중 하나입니다.

Defer와 Async란?

HTML 내에서 스크립트 태그가 기본적으로 사용될 경우 브라우저는 HTML 파싱을 중단하고 JavaScript 파일을 다운로드한 후 실행하며 페이지 생성을 계속합니다. 이 동작은 중요한 스크립트에 대해 가끔 필요하지만 모든 파일에 대해 사용될 경우 불필요한 대기를 초래합니다. defer와 async 속성은 이 동작을 변경하여 파일의 다운로드와 실행을 서로 다른 규칙에 따라 처리합니다.

Defer는 어떻게 작동하나요?

defer가 추가된 스크립트 파일은 HTML 파싱이 계속되는 동안 백그라운드에서 다운로드되지만 실행은 HTML 문서가 파싱된 후에 이루어집니다. 또한 defer를 사용하는 여러 파일은 HTML 내에서 작성된 순서를 유지합니다. 따라서 서로 의존적인 JavaScript 파일에는 대부분 안전한 선택입니다. 예를 들어, 먼저 라이브러리가 있고, 그 다음에 해당 라이브러리에 의존하는 테마 스크립트가 실행되어야 한다면 defer가 적합할 수 있습니다.

예시 사용법은 다음과 같습니다: <script defer src=/js/app.js></script>. 이 경우 app.js 파일은 페이지의 초기 렌더링을 차단하지 않고 다운로드되며, DOM 준비가 완료되면 순서대로 실행됩니다. 현대 브라우저에서는 defer가 널리 지원되며, 전통적인 스크립트 파일에 대해 신뢰할 수 있는 최적화 도구입니다.

Async는 어떻게 작동하나요?

async가 추가된 스크립트도 HTML 파싱이 계속되는 동안 다운로드되지만, 다운로드가 완료되는 즉시 실행됩니다. 이 과정에서 HTML 파싱이 잠시 중단될 수 있습니다. async는 파일 간의 순서를 보장하지 않습니다. 먼저 다운로드된 파일이 먼저 실행됩니다. 따라서 독립적으로 실행되는 분석, 광고, 추적 픽셀, 외부 위젯 또는 소셜 미디어 스크립트에 더 적합합니다.

예시 사용법: <script async src=/js/analytics.js></script>. 이 파일은 다른 로컬 스크립트의 실행을 기다려서는 안 됩니다. 만약 analytics.js가 페이지에서 나중에 정의된 변수나 jQuery와 같은 다른 라이브러리에 의존하고 있다면 async는 오류를 발생시킬 수 있습니다. 따라서 async는 빠르지만 주의 깊은 분류가 필요합니다.

Defer와 Async 비교 표

실용적인 규칙은 다음과 같습니다: 파일이 순차적으로 실행되어야 한다면 defer로 시작하세요. 파일이 완전히 독립적이라면 async를 고려하세요. 확실하지 않다면 먼저 스테이징 환경에서 defer를 시도해보고, 콘솔 오류 및 중요한 상호작용을 테스트하세요. 스테이징 환경과 백업 가이드

지연된 JavaScript 로딩을 위한 단계별 실행 계획

무작위로 모든 스크립트 태그에 defer 또는 async를 추가하는 것은 단기적으로 점수를 높일 수 있지만, 실제 운영 사이트에서 결제, 검색, 메뉴, 폼 검증 또는 장바구니와 같은 중요한 기능을 방해할 수 있습니다. 건강한 적용을 위해서는 측정, 분류, 작은 변경, 테스트 및 모니터링 주기를 사용해야 합니다.

1. 현재 성능 측정

시작하기 전에 기준 값을 설정하세요. PageSpeed Insights로 모바일 및 데스크톱 점수를 기록합니다. Lighthouse 보고서에서 TBT, First Contentful Paint, Largest Contentful Paint 및 Speed Index 값을 기록합니다. Chrome DevTools Performance 탭에서 메인 스레드를 검사하세요; 긴 노란색 블록은 대부분 JavaScript 파싱, 컴파일 및 실행 비용을 나타냅니다.

예시 시작 표를 다음과 같이 준비할 수 있습니다: 모바일 TBT 780ms, JavaScript 실행 시간 2.8초, 메인 스레드 작업 4.5초. 최적화 후 모바일 TBT가 280ms로 감소하면 약 64% 개선을 달성한 것입니다. 이러한 구체적인 기록은 팀 내에서 어떤 변경이 효과가 있었는지 쉽게 확인할 수 있게 합니다.

2. 스크립트 인벤토리 만들기

페이지의 소스 코드 또는 네트워크 탭에서 로드된 모든 JavaScript 파일을 나열하세요. 각 파일의 출처, 크기, 필요 시점 및 종속성을 파악하세요. 파일을 다음 그룹으로 나누는 것이 도움이 됩니다:

• 중요 스크립트: 첫 화면이나 기본 내비게이션용으로 즉시 필요한 코드.
• 종속 로컬 스크립트: 테마, 슬라이더, 필터, 갤러리 및 애플리케이션 모듈.
• 독립적인 제3자 스크립트: 분석, 광고, 픽셀, 채팅 및 소셜 미디어 구성 요소.
• 불필요하거나 구식 스크립트: 사용하지 않는 플러그인에서 남은 파일.
• 조건부로 로드해야 하는 스크립트: 특정 페이지에서만 필요한 것, 예를 들어 연락처 페이지의 폼 검증.

최고의 최적화는 때로는 defer를 추가하는 것이 아니라 아예 필요 없는 스크립트를 제거하는 것입니다. 90KB로 압축된 파일은 모바일 기기에서 파싱 및 실행을 포함하여 300ms 이상의 비용을 발생시킬 수 있습니다. 따라서 먼저 불필요한 것을 정리한 후, 남은 것들을 지연시키는 것이 더 올바른 접근입니다.

3. Defer 적용할 파일 식별

일반적으로 메인 테마 스크립트, 메뉴 동작, 슬라이더 코드, 제품 갤러리 모듈 및 애플리케이션 번들 파일은 defer의 좋은 후보입니다. 그러나 여기서 중요한 조건은 document.write와 같은 구식이고 차단적인 방법에 지나치게 의존하지 않으며 DOM이 준비된 후에 실행되는 것이 허용될 수 있어야 합니다.

WordPress 테마에서는 jquery-migrate, 테마 메인 파일 및 플러그인 스크립트가 복잡한 종속성을 가질 수 있습니다. jQuery 코어를 async로 설정하는 것은 많은 사이트에서 위험할 수 있습니다; 왜냐하면 많은 플러그인이 jQuery 순서를 기다리기 때문입니다. 대신 jQuery에 의존하는 파일에 대해 통제된 defer를 적용하거나 플러그인 수준에서 최적화된 로딩 옵션을 사용하는 것이 더 안전합니다. 워드프레스 속도 최적화 가이드

4. Async 적용할 파일 선택

Google Analytics, 광고 태그, Facebook Pixel, LinkedIn Insight Tag, 일부 외부 채팅 위젯 및 소셜 공유 코드는 async의 후보입니다. 하지만 모든 제3자 스크립트가 동일한 것은 아닙니다. 일부 라이브 지원 도구는 페이지가 로드되면 사용자 세션을 생성하고 싶어할 수 있으며, 일부 광고 시스템은 특정 컨테이너 순서를 기다릴 수 있습니다. 따라서 문서를 확인하는 것이 필요합니다.

독립적인 분석 코드를 async로 설정하는 것은 일반적으로 사용자 경험에 해를 끼치지 않습니다. 하지만 데이터 손실 위험을 줄이기 위해 실시간 보고서에서 트리거 확인을 수행하세요. 태그 관리자 사용 시 모든 태그를 단일 컨테이너에 쌓기보다는 트리거 조건을 조정하세요. 예를 들어, 댓글 양식이 없는 페이지에서는 댓글 추적 스크립트가 로드되지 않아야 하고, 제품 페이지가 없는 페이지에서는 제품 상호작용 스크립트가 로드되지 않아야 합니다.

5. 조건부 및 이벤트 기반 로딩 추가

defer와 async는 좋은 시작점이지만, 사용자 행동에 따라 JavaScript 파일을 로드하는 것이 TBT에 더 큰 영향을 미칠 수 있습니다. 라이브 지원 상자는 페이지가 열리자마자가 아니라 사용자가 5초를 머물거나 도움 버튼을 클릭했을 때 로드될 수 있습니다. 지도 임베드 코드는 사용자가 연락처 섹션으로 스크롤할 때 로드될 수 있습니다. 비디오 플레이어 스크립트는 사용자가 재생 버튼을 클릭할 때 호출될 수 있습니다.

이 접근 방식은 특히 콘텐츠 사이트 및 기업 웹사이트에서 효과적입니다. 사용자가 모든 위젯을 필요로 하는 것은 아니기 때문입니다. 초기 로드에서 200KB의 JavaScript를 제거하는 것은 저사양 모바일 프로세서에서 TBT 값을 수백 밀리초 감소시킬 수 있습니다.

6. 테스트하고 단계적으로 배포

변경 사항을 직접 라이브 사이트에 적용하기보다는 테스트 환경에서 시도해보세요. 홈 페이지, 카테고리 페이지, 제품 또는 서비스 페이지, 연락처 페이지, 로그인 양식 및 결제 흐름과 같은 중요한 페이지에서 수동 테스트를 수행하세요. 브라우저 콘솔에서 오류가 있는지 확인하세요. 특히 Cannot read property, is not defined 및 undefined function과 같은 오류는 순서 또는 종속성 문제를 나타냅니다.

라이브 전환 시 소규모 그룹으로 진행하세요. 먼저 독립적인 제3자 스크립트를 최적화한 후 테마 스크립트로 넘어갑니다. 각 변경 후 Lighthouse 보고서를 동일한 네트워크 및 장치 시뮬레이션으로 반복하세요. 단일 측정에 의존하지 마세요; 세 번의 테스트 평균을 내는 것이 더 건강한 결과를 제공합니다.

WordPress 사이트에서 Defer와 Async 적용 시 유의사항

WordPress 생태계에서 JavaScript 파일은 테마 및 플러그인을 통해 wp_enqueue_script 함수로 로드됩니다. 2026년부터는 최신 WordPress 버전에서 스크립트 전략을 보다 통제된 방식으로 정의할 수 있습니다. 그러나 구형 테마, 페이지 빌더 플러그인 및 호환되지 않는 최적화 플러그인은 충돌을 일으킬 수 있습니다.

퍼포먼스 플러그인을 사용하는 경우 모든 JavaScript를 한 번에 지연시키기보다는 제외 목록을 만드세요. 결제 페이지, 회원 로그인, 관리자 바, 보안 인증 및 CAPTCHA 스크립트는 민감할 수 있습니다. WooCommerce를 사용하는 사이트에서는 장바구니 조각, 결제 게이트웨이 스크립트 및 변형 선택기가 반드시 테스트되어야 합니다. WooCommerce 호스팅 솔루션

WordPress에 대한 실용적인 순서는 다음과 같을 수 있습니다: 먼저 사용하지 않는 플러그인을 제거하세요. 그 다음 필요한 페이지에서만 로드되어야 하는 플러그인 파일을 조건부로 설정하세요. 그런 다음 테마 및 플러그인 스크립트에서 defer를 시도하세요. 마지막으로 독립적인 제3자 코드에서 async 또는 지연된 로딩을 사용하세요. 이 방법은 한 번에 큰 충돌을 겪을 위험을 줄입니다.

맞춤형 소프트웨어 및 프레임워크 프로젝트에서 주의할 점

React, Vue, Angular, Next.js, Nuxt 또는 유사한 현대적인 구조에서 JavaScript 최적화는 단순히 HTML 태그에 defer를 추가하는 것에 그치지 않습니다. 패키지 크기, 코드 분할, 트리 흔들기, 동적 import 및 hydration 비용이 TBT에 결정적인 영향을 미칩니다. 단일 큰 번들 파일이 700KB인 경우 defer를 사용하더라도 실행 단계에서 메인 스레드가 오랜 시간 동안 차단될 수 있습니다.

맞춤형 소프트웨어 프로젝트에서는 경로 기반 코드 분할을 사용하세요. 사용자가 홈페이지에 있을 때 관리 패널, 그래픽 라이브러리 또는 고급 편집기 코드는 다운로드되어서는 안 됩니다. 무거운 구성 요소는 동적 import를 통해 필요할 때 호출하세요. 사용하지 않는 종속성은 패키지 분석 도구로 식별하세요. 큰 날짜, 그래픽 또는 애니메이션 라이브러리 대신 더 가벼운 대안을 고려하세요.

서버 측 렌더링 또는 정적 생성을 사용하는 프로젝트에서도 주의가 필요합니다. HTML이 빨리 도착하더라도 hydration 단계에서 수백 개의 구성 요소가 동시에 활성화되면 TBT 값이 증가할 수 있습니다. 상호작용이 없는 콘텐츠에서는 불필요한 클라이언트 측 JavaScript를 피하는 것이 2026년 성능 접근 방식의 중심입니다.

호스팅, 서버 응답 시간 및 JavaScript 성능의 관계

TBT는 브라우저의 JavaScript 실행 시간과 직접적으로 관련이 있지만 호스팅 인프라는 간접적으로 결과에 영향을 미칩니다. 느린 TTFB, 압축 부족, HTTP/2 또는 HTTP/3 지원 부족, 약한 캐싱 및 먼 위치로 인한 지연은 JavaScript 파일이 더 늦게 도달하게 만듭니다. 파일이 늦게 도착하면 페이지 생명주기가 길어지고 사용자 경험이 저하됩니다.

양질의 호스팅 인프라는 Brotli 또는 Gzip 압축, 활성 브라우저 캐시, 최신 PHP 버전, 빠른 디스크 기술 및 CDN 통합을 통해 최적화를 지원합니다. SSL 인증서의 올바른 설치는 현대 브라우저 기능, HTTP/2 및 안전한 제3자 통합 측면에서 중요합니다. Hostragons SSL 인증서 Hostragons 도메인 조회

예를 들어, 동일한 JavaScript 파일이 압축 없이 320KB일 때 Brotli를 사용하면 95KB 수준으로 줄일 수 있습니다. 이는 TBT 값을 직접적으로 같은 비율로 줄이지는 않지만, 다운로드 시간이 단축되고 리소스 우선순위가 완화되며 전체 로딩 경험이 개선됩니다. 따라서 defer, async, 캐싱 및 올바른 호스팅은 함께 고려되어야 합니다.

측정 및 검증 체크리스트

최적화가 성공했는지 확인하기 위해서는 단순히 PageSpeed 점수만 확인하는 것으로는 충분하지 않습니다. 아래 체크리스트는 실제 영향을 보다 정확하게 평가하는 데 도움이 됩니다:

• 모바일 TBT 값이 최적화 전후로 비교되었나요?
• JavaScript 실행 시간 보고서에서 가장 비용이 많이 드는 파일이 줄어들었나요?
• Chrome DevTools Performance 기록에서 긴 작업 수가 줄어들었나요?
• 콘솔에 JavaScript 오류가 있나요?
• 메뉴, 검색, 필터, 폼, 장바구니 및 결제 흐름이 원활하게 작동하나요?
• 제3자 분석 및 광고 태그가 정확하게 트리거되고 있나요?
• 실제 사용자 데이터에서 INP 및 상호작용 지연이 개선되었나요?
• 변경 사항이 캐시를 지운 후 다시 테스트되었나요?

여기서 중요한 점은 실험실 데이터와 실제 데이터를 구분하는 것입니다. TBT는 Lighthouse 실험실 메트릭입니다. 실제 사용자 경험에서는 Interaction to Next Paint(INP)가 더 결정적인 요소가 되었습니다. 그러나 TBT 감소는 대개 INP 개선에 기여합니다; 이는 메인 스레드에서 더 적은 차단이 발생하기 때문입니다.

자주 발생하는 실수 및 피하는 방법

모든 스크립트를 동시에 async로 설정하기

이것은 가장 일반적인 실수 중 하나입니다. async는 순서 보장을 제공하지 않기 때문에 종속 파일에서 무작위 오류를 발생시킬 수 있습니다. 한 페이지에서 문제가 없어 보이는 구조가 느린 연결이나 다른 브라우저에서는 깨질 수 있습니다. 종속성이 있는 파일에서는 defer가 더 안전한 시작입니다.

jQuery와 종속 플러그인을 잘못 지연시키기

특히 WordPress 사이트에서는 많은 플러그인이 jQuery 순서에 의존합니다. jQuery 코어를 async로 설정하면 플러그인 코드가 jQuery가 로드되기 전에 실행될 수 있습니다. 해결책은 종속성 네트워크를 보고 중요한 파일을 제외 목록에 추가하는 것입니다.

제3자 스크립트를 통제 없이 방치하기

사이트 소유자는 자신의 테마 파일을 최적화하는 동안 광고, 채팅 및 분석 코드를 잊어버릴 수 있습니다. 그러나 Lighthouse 보고서에서는 가장 무거운 작업이 대부분 제3자 리소스에서 발생하곤 합니다. 사용하지 않는 태그를 제거하고, 조건부로 트리거하며, 필요할 경우 사용자 상호작용에 따라 지연시키는 것이 중요한 이득을 가져옵니다.

측정 없이 플러그인 설치하기

퍼포먼스 플러그인은 유용할 수 있지만, 측정 없이 사용하는 모든 추가 도구는 새로운 JavaScript 및 CSS 로드를 가져올 수 있습니다. 먼저 문제를 진단한 후 도구를 선택하세요. 플러그인이 실제로 TBT를 낮추는지 테스트 보고서로 확인하세요.

캐시 및 미니피케이션 충돌 무시하기

미니피케이션, 병합, defer 및 async를 동시에 적용하면 파일 순서가 변경될 수 있습니다. 이로 인해 운영 환경에서 예기치 않은 오류가 발생할 수 있습니다. 특히 CDN, 서버 캐시 및 애플리케이션 캐시를 함께 사용할 때는 변경 후 모든 레이어를 정리해야 합니다.

현실적인 최적화 시나리오

중간 규모의 기업 웹사이트에서 홈 페이지에 18개의 JavaScript 요청이 있다고 가정해봅시다. 이 중 5개는 테마 및 메뉴 동작, 4개는 슬라이더 및 애니메이션, 3개는 폼 및 지도, 6개는 분석, 픽셀 및 라이브 지원 코드입니다. 초기 Lighthouse 모바일 TBT 값이 920ms로 측정됩니다.

첫 번째 단계에서는 사용하지 않는 두 개의 애니메이션 플러그인을 제거하고 140KB의 압축된 JavaScript 로드를 줄입니다. TBT는 760ms로 감소합니다. 두 번째 단계에서는 테마 및 슬라이더 파일을 defer로 설정하고, 종속성을 테스트합니다. TBT는 480ms로 줄어듭니다. 세 번째 단계에서는 지도 스크립트를 오직 연락처 섹션으로 스크롤할 때만 로드하고, 라이브 지원은 7초 후에 시작하며, 분석 및 픽셀 코드는 async로 전환합니다. 마지막 측정에서 TBT는 210ms로 감소합니다.

이 시나리오는 단일 마법 같은 설정 대신 계층적 접근의 중요성을 보여줍니다. Defer와 async는 강력한 도구이지만, 최상의 결과는 불필요한 코드를 제거하고, 조건부 로딩을 하고, 올바른 캐싱과 양질의 인프라와 함께 이루어집니다.

결론: 더 낮은 TBT를 위한 균형 잡힌 및 검증된 JavaScript 전략

사이트에서 지연된 JavaScript 로딩을 적용하는 것은 TBT 시간을 줄이는 가장 실용적이고 효과적인 방법 중 하나입니다. defer는 순서적이고 DOM 이후에 작동하기 적합한 파일에 안전한 솔루션을 제공하며, async는 독립적인 제3자 스크립트를 보다 유연하게 로드하는 데 이상적입니다. 성공적인 최적화를 위해서는 먼저 측정하고, 스크립트를 분류하며, 불필요한 파일을 제거하고, 변경 사항을 단계적으로 테스트하며, 실제 사용자 경험을 모니터링해야 합니다.

Hostragons에서 빠르고 안전하며 확장 가능한 인프라를 활용하면 JavaScript 최적화, 캐싱 및 SSL 구성을 통해 보다 안정적인 웹 성능을 얻는 데 도움이 됩니다. 사이트의 TBT 값을 개선하고 싶다면 먼저 현재 보고서를 작성하고, 그 다음 작지만 측정 가능한 단계를 밟아 나가세요. 적절한 호스팅 및 성능 인프라를 위해 Hostragons 솔루션을 살펴볼 수 있습니다. Hostragons 웹 호스팅 패키지

자주 묻는 질문

Defer와 async를 동시에 사용할 수 있나요?

클래식 스크립트 태그에서 defer와 async를 함께 사용하면 현대 브라우저에서는 async가 우선적으로 동작할 수 있습니다; 이는 순서 보장을 없애버립니다. 따라서 실제로 두 가지를 동일한 파일에서 함께 사용하는 것은 권장되지 않습니다. 종속 파일에서는 defer, 독립 파일에서는 async를 선택하는 것이 더 안전합니다.

지연된 JavaScript 로딩이 SEO 순위를 직접적으로 높이나요?

단독으로는 직접적인 순위를 보장하지 않지만, 페이지 경험, 상호작용 속도 및 Core Web Vitals 성능을 개선하여 SEO 성공을 지원합니다. 더 빠르게 반응하는 페이지는 사용자 만족도, 전환 및 크롤링 품질 인식을 높일 수 있습니다.

모든 JavaScript 파일에 defer를 추가하는 것이 안전한가요?

아니요. 일부 스크립트는 페이지의 초기 단계에서 작동해야 하거나 다른 파일의 특정 순서 로드에 의존할 수 있습니다. 따라서 각 파일의 목적, 종속성 및 실행 시간을 확인해야 하며, 변경 사항은 테스트 환경에서 시도해야 합니다.

TBT를 줄이기 위해 단지 defer와 async만으로 충분한가요?

소규모 및 중간 규모 사이트에서는 큰 개선을 가져올 수 있지만, 무거운 프레임워크를 사용하는 사이트, 많은 제3자 코드를 포함하는 사이트 또는 큰 번들 파일을 가진 사이트에서는 추가 조치가 필요합니다. 코드 분할, 사용하지 않는 JavaScript 제거, 조건부 로딩, 캐싱 및 강력한 호스팅 인프라가 함께 고려되어야 합니다.

WordPress 사이트에서 어떤 스크립트를 async로 설정하지 말아야 하나요?

jQuery에 의존하는 플러그인 파일, 결제 및 장바구니 스크립트, 폼 검증, 보안 인증 및 중요한 테마 기능은 무작위로 async로 설정해서는 안 됩니다. 이 파일들에서 순서가 깨지면 사용자 작업이 중단될 수 있습니다. 먼저 defer를 시도하고, 필요하다면 제외 목록을 만들어야 합니다.