웹사이트 속도를 높이는 방법: 웹 페이지 로드 시간을 줄이기 위한 15가지 빠르고 쉬운 수정

오늘의 게시물에서는 웹사이트 로드 시간을 빠르고 쉽게 줄이는 방법(그리고 이것이 왜 중요한지)을 보여드리겠습니다.

사실로:

내가 공개하려는 기술은 페이지 속도를 완전히 로드되는 3초 이상에서 1.2초로 높이는 데 사용한 것과 동일한 전략입니다.

하지만 가장 좋은 점은 다음과 같습니다.

이러한 웹 사이트 로딩 개선 사항 중 어느 것도 개발자 노하우가 필요하지 않으며 초보자도 초고속으로 구현할 수 있습니다.

사이트 속도를 높이고 순위를 높이며 참여를 높이고 더 많은 트래픽을 전환하려면 이 게시물이 적합합니다. 하지만 먼저 빠른 웹페이지 로드 시간이 왜 중요한가요?

웹사이트 로드 시간 통계

• 로드 속도가 느린 경우 사용자의 59.2%가 처음 6초 이내에 웹사이트를 떠납니다. – Unbounce
• 페이지 로드 시간이 1초에서 이동함에 따라 이탈 확률이 32% 증가합니다. – Think With Google
• 로드 시간을 0.1초 줄이면 리드 생성 페이지의 이탈률이 8.3% 향상됩니다(Google, Fifty-Five, Deloitte).
• 로드 시간이 0.1초만 단축되는 경우:
  • 소매 고객 참여가 5.2% 증가합니다.
  • Google, Fifty-Five, Deloitte 등 소매 및 여행 카테고리의 제품 목록 페이지 이탈률이 5.7% 및 5.4% 향상되었습니다.
• 웹사이트 전환율은 0초에서 5초 사이의 로드 시간이 1초 추가될 때마다 평균 4.42% 감소합니다. – Portent
• 사이트 로드 시간을 1/10초로 늘리면 전환율이 7% 감소합니다. – Akamai
• 사이트 로드 시간을 10분의 1초로 줄이면 소매 사이트의 경우 전환율이 8.4% 증가하고 Google, Fifty-Five 및 Deloitte와 같은 여행 사이트의 경우 전환율이 10.1% 증가합니다.
• 전자 상거래 사이트가 예상보다 느리게 로드되는 경우 45% 이상의 사람들이 구매 가능성이 낮다고 인정합니다 – Unbounce
• 약 70%의 사람들이 페이지의 속도가 온라인 소매업체에서 구매하려는 의향에 영향을 미친다고 말합니다. – Unbounce
• 스마트폰 쇼핑객의 77%는 빠르게 구매할 수 있는 모바일 사이트에서 구매할 가능성이 더 높다고 말합니다. – Think with Google
• 소매 사이트에서는 로드 시간이 10분의 1초 감소할 때 평균 주문 가치가 9.2% 증가합니다. – Deloitte
• 모바일 웹페이지가 시각적으로 로딩을 완료하는 데 걸리는 평균 시간은 21.6초입니다 – Backlinko
• 데스크톱 웹 페이지가 시각적으로 로드를 완료하는 데 걸리는 평균 시간은 8.2초입니다. – Backlinko
• 완전히 로드된 웹 페이지의 평균 페이지 로딩 속도는 모바일에서 27.3초입니다. – Backlinko
• 완전히 로드된 웹 페이지의 평균 페이지 로딩 속도는 데스크탑에서 10.3초입니다. – Backlinko
• 평균 웹 페이지는 데스크톱보다 모바일에서 완전히 로드되는 데 87.84% 더 오래 걸립니다. – Backlinko
• 느리게 로드되는 모바일 페이지는 데스크톱 페이지에 비해 이탈률이 2배 더 높고 페이지 조회수가 27% 감소합니다. – 완벽함

이제 빠르게 로드되는 웹사이트의 중요성을 이해했으므로 페이지 속도가 (정확하게) 무엇이며 어떻게 개선할 수 있는지 알아보겠습니다.

페이지 속도란 무엇입니까?

페이지 속도는 웹 페이지가 로드되는 데 걸리는 시간입니다.

로딩 시간이라고도 하는 페이지 속도는 웹 페이지를 요청하는 브라우저와 브라우저가 페이지를 렌더링하는 시간 사이의 간격으로 측정됩니다.

페이지의 로딩 속도는 데이터 이동 거리, 웹사이트의 서버 속도, 코드의 복잡성, 페이지 파일 크기, 연결 유형과 같은 다양한 요인의 영향을 받습니다.

말할 것도 없이, 파일 압축, 캐싱, 렌더링 차단 및 페이지 속도와 SEO에 영향을 미치는 수십 가지 기타 요소.

알다시피 페이지 속도를 개선하는 것은 페이지 속도 플러그인을 설치하는 것만큼 간단하지 않습니다.

속도에 기여하는 수많은, 때로는 복잡한 요소가 있습니다. – 또는 느리게 – 웹사이트가 로드됩니다.

뿐만 아니라 페이지의 로드 시간을 측정하는 "단방향"도 없으며 여러 가지가 있습니다.

다음은 가장 일반적인 세 ​​가지입니다.

페이지 로드 시간

페이지가 완전히 로드되는 데 걸리는 시간입니다.

완전히 로드되는 시간은 스크립트 및 코드와 같은 숨겨진 요소뿐만 아니라 페이지의 모든 보이는 부분의 로드를 측정합니다. 기본적으로 페이지에 있는 모든 리소스의 100% 로드 시간을 측정합니다.

이해하기 가장 간단한 페이지 속도 측정항목이지만 가장 유용한 것은 아닙니다. 페이지가 완전히 로드되기 훨씬 전에 페이지가 사용자에게 로드된 것처럼 보일 수 있고 실제로는 작동할 수 있기 때문입니다.

가장 큰 콘텐츠가 포함된 페인트

LCP(Large Contentful Paint)는 사용자의 관점에서 페이지의 로드 시간을 결정하는 보다 가치 있는 메트릭입니다.

웹 페이지가 화면에서 가장 큰 콘텐츠를 사용자에게 표시하는 데 걸리는 시간을 측정합니다.

일반적으로 페이지 헤드라인, 추천 이미지 또는 주요 텍스트 콘텐츠입니다.

간단히 말해 LCP는 스크롤 없이 볼 수 있는 중요한 콘텐츠가 사용자에게 완전히 표시되는 시간을 측정합니다.

예를 들어 페이지가 완전히 로드되는 데 10초가 걸린다고 가정해 보겠습니다.

첫 번째 콘텐츠가 포함된 페인트가 몇 초 이내에 발생하는 한 페이지는 느리게 로드되는 "나타나지" 않습니다.

요컨대, 가장 큰 내용이 포함된 페인트가 빠르면 완전히 로드된 시간이 느려질 수 있습니다.

첫 번째 바이트까지의 시간

간단히 말해서 웹 브라우저가 웹 사이트 서버에서 데이터의 첫 번째 바이트를 수신하기 전에 기다려야 하는 시간을 측정한 것입니다.

TTFB는 실제로 페이지를 로드하는 데 걸리는 시간을 측정하지 않지만 페이지 로드 시간에 영향을 미칩니다.

브라우저가 서버에서 데이터를 수신하는 데 시간이 오래 걸릴수록 페이지를 표시하는 데 더 오래 걸립니다.

페이지 로드 시간을 계산하는 방법?

페이지 속도를 측정하는 방법에는 여러 가지가 있습니다.

• 첫 번째 바이트까지의 시간(TTFB)
• 최대 함량 페인트(LCP)
• 첫 번째 의미 있는 페인트(FMP)
• 인터랙티브 시간(TTI)
• 첫 번째 입력 지연(FID)

목록은 계속됩니다…

그리고 이러한 메트릭 중 어느 것도 다른 것보다 낫지 않기 때문입니다.

모든 웹사이트에서 웹사이트 속도를 높이는 작업을 하는 것이 좋습니다.

괜찮아요. 잠시 후 방법을 보여 드리겠습니다. 하지만 먼저 다음을 수행합니다.

페이지 속도가 SEO에 중요한 이유는 무엇입니까?

부정할 수 없습니다. Google은 페이지 로드 속도에 집착합니다.

2010년 이후로 Google은 사이트 속도(따라서 페이지 속도)를 검색 엔진 알고리즘의 순위 요소로 사용했습니다.

그런 다음 2018년에 Google은 느린 로딩 페이지의 검색 엔진 순위에 추가로 영향을 미치는 "속도 업데이트"를 출시했습니다.

그리고 가장 최근인 2021년에 Google은 핵심 웹 바이탈과 로딩 속도를 주요 구성 요소로 하는 Page Experience를 도입했습니다.

Google은 페이지 속도에 대해 많은 관심을 가지고 있습니다. 그런데 왜 그렇지 않습니까?

Google이 웹사이트에 엄청난 양의 무료 트래픽을 보내려는 경우 사용자가 멋진 경험을 하기를 바랍니다. 그 중 큰 부분은 빠르게 로딩되는 웹페이지입니다.

간단히 말해서:

로딩 속도가 느린 웹사이트는 Google 순위를 손상시킵니다.

빠르게 로드되는 웹사이트는 Google 순위에 도움이 됩니다.

유일한 질문은 페이지 로드 시간을 어떻게 개선할 것인가입니다. 다음에 다룰 것입니다.

웹사이트 속도를 높이는 방법: 웹 페이지 로드 시간을 줄이는 15가지 모범 사례

피할 수 있는 방법은 없으며 페이지 속도에 기여하는 많은 부분이 코드에 깊숙이 뿌리를 두고 있고 고도로 기술되어 있습니다.

AMP 페이지 생성, HTTP 요청 최소화, 비동기 로딩 사용 등 모두 개발자 수준의 노하우가 필요합니다. 그리고 그 때문에 이 게시물에서 페이지 속도 최적화에 대해 논의하지 않겠습니다.

대신 사이트 속도를 전례 없이 높일 수 있는 구현하기 쉬운(그러나 종종 잊혀지는) 방법 15가지를 공유합니다.

뛰어들자:

(1). 로딩 시간을 벤치마킹하고 개선할 점을 알 수 있도록 페이지 속도 테스트를 수행하십시오.

페이지 속도를 개선하기 전에 웹 사이트 로드 속도를 아는 것이 도움이 됩니다.

결국 현재 페이지 속도를 모르는 경우 속도 최적화가 성공적인지 어떻게 알 수 있습니까?

여러 도구를 사용하여 페이지 속도 향상을 평가할 수 있으며 모든 도구를 통해 사이트를 실행하는 것이 좋습니다.

그러나 빠른 경고:

당신의 점수는 도구마다 크게 다를 것입니다.

각 웹 페이지 속도 테스트 도구는 성능을 평가하기 위해 다른 방법을 사용하기 때문입니다. 뿐만 아니라 서버 위치는 다양한 도시에 있으며 나중에 알게 되겠지만 서버 위치는 웹사이트 로드 시간에 큰 영향을 미칩니다.

세부 사항에 집착할 필요가 없습니다. 지금은 각 도구로 테스트를 실행하고 점수를 기록해 둡니다.

핑덤

웹 브라우저에서 페이지가 로드되는 방식을 모방한 사용하기 쉬운 사이트 속도 테스트입니다. Pingdom은 현재 사이트를 테스트할 수 있는 7개의 서버 위치를 제공합니다.

페이지가 완전히 로드된 시점에 따라 로드 시간을 측정하는 다른 도구와 달리 Pingdom은 페이지의 모든 리소스가 다운로드된 시점을 기록하는 On Load Time을 사용합니다. 이 시점에서 페이지는 대화형이지만 스크립트는 여전히 백그라운드에서 실행될 수 있습니다.

GT 메트릭스

데스크톱 및 모바일 측정과 여러 브라우저에서 테스트할 수 있는 옵션을 모두 제공하는 페이지 속도 테스트 도구입니다. GT Metrix는 무료 플랜의 7개와 프로 플랜의 추가 15개를 포함하여 다양한 서버 위치를 제공합니다.

기본 측정은 완전히 로드된 시간이며 온로드 시간은 선택 사항입니다.

웹페이지 테스트

WebPageTest는 다양한 브라우저에서 웹사이트의 속도와 성능을 보여주는 또 다른 훌륭한 도구입니다.

WebPageTest는 총 38곳으로 가장 광범위한 테스트 위치를 가지고 있습니다. GT Metrix와 마찬가지로 WebPage Test는 기본적으로 완전히 로드된 시간을 사용하며 로드 시간(문서 완료 시간이라고도 함)은 선택 사항입니다.

PageSpeed ​​인사이트

이것은 페이지 속도 성능을 평가하기 위한 Google의 도구입니다. 위에서 언급한 세 가지 도구와 달리 Google은 현장 데이터를 사용할 수 있다고 가정하고 점수에 실험실 데이터 대신 현장 데이터를 사용합니다.

이게 무슨 뜻이야:

Google PageSpeed ​​Insights는 실제 사용자의 로드 시간을 시뮬레이션하는 테스트를 실행하는 대신 Chrome 브라우저 사용자로부터 실제 사용자 데이터를 수집합니다. 이 데이터는 30일 동안 집계되므로 로드 시간을 최적화한 후 30일이 지나야 점수가 향상될 수 있습니다.

로드 시간에 대한 Google의 평가를 아는 것이 중요합니다. 검색 엔진 순위 성능에 기여하는 페이지 경험 신호의 핵심 부분인 Core Web Vitals에 사용하는 점수입니다.

즉, 다른 세 가지 도구(Pingdom, GT Metrix 및 WebPageTest)는 페이지 속도 성능의 빠른 전후 측정에 더 유용합니다.

몇 가지 포인터:

먼저 타겟 고객과 가까운 테스트 위치를 선택합니다. 테스트가 미국에서 실행되지만 사용자가 호주에 있는 경우 페이지 속도 성능에 대한 현실적인 측정값을 얻을 수 없습니다.

둘째, 홈페이지만 테스트하는 실수를 하지 마십시오.

Pagespeed는 각 페이지에 고유합니다.

가장 중요한 URL을 모두 테스트하고 Google Analytics를 사용하여 가장 느린 로딩 페이지를 빠르게 식별하는 것이 좋습니다.

팁 – GA '동작' 메뉴의 '사이트 속도'에서 '페이지 타이밍'을 찾을 수 있습니다.

알겠어? 시원한.

페이지 속도 최적화를 시작해 보겠습니다.

(2). 번개처럼 빠른 DNS 호스트를 위한 무료 도메인 이름 시스템 전환

전화번호부와 같은 DNS(Domain Name System) 호스트를 생각해 보십시오.

사람이 읽을 수 있는 도메인 이름을 IP 주소(웹사이트가 실제로 위치한 곳)에 매핑합니다.

간단히 말해서:

사용자가 브라우저의 URL 표시줄에 웹 주소를 입력할 때마다 브라우저는 웹 주소를 IP 주소로 변환하는 DNS 조회를 수행하고 그렇게 함으로써 웹사이트가 호스팅되는 서버를 찾습니다.

기본적으로 도메인 등록 기관에서 제공하는 무료 DNS 서비스를 사용하게 됩니다.

NameCheap, GoDaddy, Google Domains(및 거의 모든 다른 도메인 등록기관)는 네임서버를 설정하고 도메인을 웹 호스트의 IP 주소로 라우팅하는 기능을 제공합니다.

이러한 무료 DNS 서비스에 문제가 있습니까?

그들은 정말 느립니다.

로켓처럼 빠른 웹사이트를 원한다면 DNS를 Cloudflare로 전환하는 것이 좋습니다.

Namecheap의 DNS 서비스에서 이동하여 26ms의 쿼리 시간에서 이동했습니다.

엄청난 13ms.

즉, DNS 처리 시간을 50% 단축했습니다.

무엇보다도 돈이 한푼도 들지 않았습니다.

무료 Cloudflare 계정에 가입한 후에는 도메인 등록 기관에 로그인하고 기본 네임서버를 Cloudflare로 교체하기만 하면 됩니다.

그리고 그것으로 당신은 끝났습니다.

(삼). 이 캐싱을 구현하고 로드 시간을 단축하십시오.

사용자가 웹사이트에 방문하면 (일반적으로) 다음과 같은 일이 발생합니다.

• 그들의 브라우저가 귀하의 웹 서버에 접속합니다
• 콘텐츠 관리 시스템은 데이터베이스에서 최신 데이터(예: 최근 게시물 및 페이지)를 가져옵니다.
• 웹 서버는 데이터를 HTML 페이지로 컴파일하고 방문자에게 제공합니다.

캐싱 플러그인은 처음 두 단계를 완전히 제거합니다.

방문자가 페이지를 볼 때마다 서버에 새 요청이 생성되는 것을 방지하기 위해 캐싱 플러그인은 웹 페이지의 미리 빌드된 버전을 저장하고 방문자에게 제공합니다.

그렇게 함으로써 사용자의 로드 시간을 단축합니다.

WordPress 캐싱 플러그인에 대한 권장 사항은 다음과 같습니다.

• WP 로켓 (내가 사용하는 것)
• W3 총 캐시
• WP 슈퍼 캐시

캐싱 플러그인은 데이터베이스 조회를 제거하므로 웹사이트 로드 시간을 1~3초 단축할 수 있습니다.

나쁘지 않다.

그러나 페이지를 미친 듯이 빠르게 로드하려면 다음을 권장합니다.

에지 캐싱(CDN)

웹사이트의 캐시된 버전을 중앙 웹 서버에 저장하는 페이지 캐싱과 달리…

에지 캐싱은 전 세계에 걸쳐 있는 서버 네트워크에 위치한 "에지 노드"에 전체 HTML 페이지를 저장합니다.

이게 무슨 뜻이야:

지구 반대편에 있는 서버에 요청하는 대신…

방문자가 페이지 열기를 요청하면 가까운 서버에서 전달됩니다.

페이지 캐싱과 마찬가지로 사전 구축된 버전의 웹 페이지는 즉시 액세스할 수 있도록 저장되며 데이터베이스 호출이 필요하지 않습니다.

상상할 수 있듯이 데이터가 수천 킬로미터에 비해 수백 킬로미터만 이동해야 하고 페이지가 사용자를 위해 미리 구축되어 있다면 로드 시간이 더 빨라질 것입니다.

뿐만 아니라 에지 캐싱은 많은 작업을 수행하기 때문에 웹 호스팅의 부담을 덜어주어 사이트 속도를 더욱 향상시킬 수 있습니다.

사용을 권장하는 Edge Caching 서비스는 Cloudflare의 CDN입니다.

전 세계 200개 이상의 서버:

그리고 한 달에 단돈 20달러로 절대 훔쳐갈 수 없습니다.

(4). 거대한 페이로드를 줄이기 위해 이미지 최적화

부풀려진 이미지만큼 웹사이트 속도를 늦추는 것은 없습니다.

그리고 그것은 거의 놀라운 일이 아닙니다.

이미지는 페이지 크기의 큰 부분을 차지합니다.

(당사 SEO 서비스 페이지의 전체 페이지 무게의 거의 40%).

따라서 이미지를 더 많이 최적화할수록 페이지가 더 빨리 로드됩니다.

유일한 질문은 어떻게?

먼저 모든 이미지의 크기를 필요한 가장 큰 크기로 조정하고 싶습니다.

예를 들어:

이 페이지의 이미지는 최대 너비가 640픽셀입니다.

650px 너비의 이미지를 로드했다면 페이지에 불필요한 무게를 추가했을 것입니다.

뿐만 아니라 내 CMS는 페이지 크기에 맞게 이미지 크기를 640px로 조정해야 하므로 로드 시간이 훨씬 더 느려집니다.

이를 염두에 두고 이미지 크기를 웹사이트에 업로드하기 전에 필요한 최대 크기로 조정하는 것이 좋습니다.

Pixlr과 같은 온라인 이미지 편집 도구나 컴퓨터 고유의 도구를 사용할 수 있습니다. 메커니즘은 중요하지 않습니다. 최대 가시 영역과 동일한 크기의 이미지가 필요합니다.

두 번째로 해야 할 일은 올바른 파일 형식을 선택하는 것입니다.

잘못된 파일 형식을 선택하면 무게가 추가되거나 이미지 품질이 저하될 수 있습니다.

이미지가 애니메이션되지 않는 한 PNG 또는 JPEG가 가장 가벼우므로 로드 속도가 가장 빠릅니다.

선택할 파일 형식을 확인하는 방법은 다음과 같습니다.

셋째, 가능한 한 많은 품질을 유지하면서 이미지 파일에서 불필요한 팽창을 모두 제거하고 싶습니다.

기술에 대해 걱정하지 마십시오.

Imageoptim을 설치하고 도구가 나머지 작업을 수행하도록 하십시오.

파일 크기를 절반으로 줄이는 데 도움이 될 수 있습니다.

하지만 기다려!

이미지가 이미 로드된 경우 어떻게 합니까?

좋은 소식. WordPress를 사용하는 경우 해결책이 있습니다.

WP 스무쉬!

WP Smush는 WordPress 미디어 라이브러리에 업로드하는 모든 이미지를 자동으로 압축합니다.

시각적 품질의 눈에 띄는 저하 없이 파일 크기를 2배 이상 줄입니다.

꽤 멋지죠?

이미지 파일 크기를 압축하면 웹 페이지 로드 시간을 개선하는 데 사용할 수 있는 이미지 최적화 트릭이 하나 더 있습니다.

(5). Lazy Loading을 구현하십시오(하지만 귀하의 로고에는 없음)!

이미지가 깃털처럼 가볍더라도 게시물에 그래픽을 많이 사용하면 페이지 무게가 여전히 무거울 수 있습니다(나처럼).

뿐만 아니라 페이지를 렌더링하기 위해 모든 이미지를 로드해야 하는 경우 페이지 로드 시간이 길어집니다.

지연 로딩을 입력합니다.

지연 로딩은 브라우저가 이미지를 화면에 표시해야 할 때까지 이미지 로딩을 지연시키는 것입니다.

즉, 모든 이미지가 한 번에 로드되지 않습니다.

일부 이미지(및 비디오 및 삽입과 같은 기타 자산)는 필요할 때만, 즉 사용자가 페이지의 해당 섹션으로 스크롤할 때만 연기되고 로드됩니다.

내 블로그 게시물을 자세히 보면 지연 로딩이 작동하는 것을 볼 수 있습니다.

지연 로딩은 강력합니다. 사이트 속도를 높일 수 있습니다. 그러나 지연 로딩에는 한 가지 큰 문제가 있습니다.

켜져 있으면 모든 이미지를 지연 로드합니다.

내 사이트와 같은 대부분의 사이트에는 로드 시 표시되어야 하는 이미지가 있으므로 지연 로드를 사용하면 실제로 가장 큰 콘텐츠가 포함된 페인트가 손상될 수 있습니다.

여기서 요점은 기본 지연 로딩 설정이 사용자에게 즉시 표시되어야 하는 맨 위에 있는 이미지를 포함하여 페이지의 모든 이미지에 지연 로딩 태그를 적용한다는 것입니다.

이는 다음을 의미합니다.

"스크롤 없이 볼 수 있는 부분" 이미지는 페이지 상단의 이미지가 로드되기 전에 지연 로드 JavaScript 라이브러리가 실행될 때까지 기다려야 합니다. 즉, 지연 로드 JavaScript는 가장 빠른 LCP(Contentful Paint)에 필요한 자산의 렌더링을 차단합니다.

이 문제를 해결하려면 로고의 URL과 스크롤 없이 볼 수 있는 다른 이미지(힌트! 추천 이미지)를 가져와 지연 로딩 플러그인에서 제외 항목으로 추가합니다.

저는 WP Rocket을 사용하고 있으며 설정은 다음과 같습니다.

WP Rocket을 사용하든 Autoptimize(지연 로딩을 위한 또 다른 훌륭한 플러그인)를 사용하든 이미지 로드를 연기하고 로고를 제외로 설정해야 합니다.

그와 함께 "로드 지연"으로 설정해야 하는 다른 항목으로 이동합니다.

(6) JavaScript 파일 연기 및 페이지 속도 향상

PageSpeed ​​Insights 또는 GT Metrix를 통해 사이트를 실행한 적이 있다면 다음 경고에 익숙할 것입니다.

피할 방법이 없습니다. JavaScript는 웹사이트 로드 시간에 영향을 미치는 가장 큰 원인 중 하나입니다.

하지만 왜?

누군가가 귀하의 사이트를 방문하면 귀하의 웹 서버는 귀하의 웹사이트의 HTML 콘텐츠를 사용자의 브라우저에 전달합니다.

그런 다음 사용자의 브라우저는 HTML을 통해 위에서 아래로 작업하여 페이지를 렌더링합니다.

해당 프로세스 중에 JavaScript를 찾으면 완전한 JavaScript 파일을 가져와 구문 분석할 때까지 페이지의 나머지 부분 렌더링을 중지합니다.

스크립트 파일은 크기가 크고 로드하는 데 시간이 걸릴 수 있으므로 로드 시간에 실제로 영향을 줄 수 있습니다.

거래는 다음과 같습니다.

라이브 채팅, 팝업, 위젯 또는 추적 스크립트와 같은 대부분의 JavaScript 파일은 페이지가 제대로 렌더링되는 데 필요하지 않습니다.

그렇기 때문에 페이지가 로드될 때까지 JavaScript 파일의 구문 분석을 연기하는 것이 좋습니다.

이렇게 하면 페이지의 모든 필수 콘텐츠가 로드되고 나중에 스크립트가 실행됩니다.

WordPress를 사용하는 경우 WP Rocket과 Perfmatters를 사용하면 JavaScript 렌더링을 지연할 수 있습니다.

궁금한 경우를 대비하여 다음은 제 Perfmatters 설정입니다.

귀하의 사이트에서 지연되는 스크립트는 귀하에게 고유합니다.

GT Metrix 권장 사항을 빠르게 검토하면 로드 시간을 늦추는 원인을 알 수 있습니다.

(7). 호스팅 업그레이드

모든 웹 호스트가 동일하지는 않습니다. 그것과는 거리가 멀다.

빠른 호스팅 제공업체와 느린 호스팅 제공업체 간의 응답 시간 차이는 쉽게 800밀리초가 될 수 있습니다.

별 것 아닌 것 같지만 4배의 차이가 있습니다.

나는 소수의 호스팅 제공업체만 테스트했기 때문에 개별 호스팅 제공업체를 부르지 않겠지만 호스팅 비용으로 월 4.99달러를 지출하면 사이트가 빠르게 로드되지 않을 가능성이 있습니다.

대부분의 예산 호스팅 계획은 사이트를 수백 개의 다른 웹사이트와 동일한(과부하된) 서버에 배치하여 속도 저하, 지연 및 심지어 다운타임으로 이어지기 때문입니다.

나는 대부분의 호스트의 성능에 대해 말할 수 없지만 일반적인 경험에 따르면 지불한 만큼 얻을 수 있습니다.

그래도 호스팅 제안을 찾고 있다면 제가 사용하고 개인적으로 추천할 수 있는 두 개의 프리미엄 호스트가 있습니다.

• Cloudways – 속도에 최적화된 서버 스택에서 관리되는 클라우드 호스팅으로 전 세계 60개 이상의 위치를 ​​제공합니다. 고객을위한 나의 이동 권장 사항.
• WP 엔진 – 서버 수준에서 페이지 캐싱을 사용하는 WordPress 웹사이트용 관리형 호스팅. 이 사이트가 호스팅되는 동일한 웹호스트입니다.

내 권장 사항을 따르든 다른 권장 사항을 따르든 몇 가지 요소를 찾아야 합니다.

첫째, 솔리드 스테이트 드라이브(SSD)를 사용하는 호스팅 제공업체가 필요합니다.

솔리드 스테이트 드라이브는 표준 하드 드라이브보다 훨씬 빠르므로 페이지 로드 시간이 더 짧습니다.

둘째, 귀하의 국가 또는 적어도 귀하의 대륙에 서버가 있는 호스트와 함께 가십시오.

웹사이트는 일반적으로 서버가 위치한 국가 외부에서 1초 이상 느리게 작동합니다.

이 통계를 염두에 두고 현재 멀리 떨어져 있는 저렴한 공유 서버를 사용하고 있다면 전용 로컬 SSD 서버로 업그레이드할 때입니다.

(8). 코드 정리 및 압축

간단히 말해서 페이지에서 찾은 리소스를 최소화하려고 합니다.

축소(실제로 단어인 경우)는 파일 크기를 줄이기 위해 불필요한 공백, 문자 및 주석(사실상 불필요한 요소)을 제거하는 프로세스입니다.

파일이 가벼울수록 전송할 데이터가 적고 로드 시간이 빨라집니다.

파일을 축소하는 프로세스는 일반적으로 JavaScript 및 CSS에 중점을 두지만 HTML을 포함할 수도 있습니다.

그러나 중복 요소를 찾기 위해 웹사이트의 모든 코드 라인을 샅샅이 뒤진다는 생각을 하기 전에 걱정하지 마십시오.

WP Rocket을 설치하고 몇 가지 상자를 선택하여 코드를 쉽게 축소할 수 있습니다.

WP Rocket은 코드를 자동으로 축소합니다!

파일을 줄이는 두 번째 방법은 GZIP 압축입니다.

GZIP은 컴퓨터에서 사용하는 ZIP 및 RAR 압축과 유사하게 작동하지만 서버에서 처리합니다.

기본적으로 방문자가 웹사이트에 방문하면 방문자의 브라우저가 웹 서버에서 사이트 파일을 요청합니다. GZIP이 활성화되면 서버는 해당 파일을 사용자의 브라우저로 보내기 전에 압축합니다.

그리고 이러한 파일이 압축되어 더 가볍기 때문에 전송 속도가 더 빠릅니다.

WP 엔진 호스팅을 사용하기 때문에 GZIP이 이미 활성화되어 있습니다.

호스팅이 GZIP 압축을 지원하지 않는 경우 WP Rocket 또는 W3 Total Cache를 통해 활성화할 수 있습니다.

또는 이런 종류의 일에 능숙한 경우 수동으로 수행하십시오.

(9). 더 빠른 HTTP2 프로토콜을 활용하려면 오래된 HTTP를 버리십시오.

이 시대에 이런 말을 하다니 믿을 수가 없다.

그러나 HTTP(HTTPS와 반대) 프로토콜에서 웹사이트를 계속 실행하고 있다면 지금 전환하십시오.

HTTPS가 순위 신호라는 것을 알고 있을 것입니다.

기본적으로 귀하의 웹사이트가 안전하고 암호화된 HTTPS 프로토콜을 사용하는 경우 Google은 귀하의 사이트에 약간의 순위 상승을 제공합니다. 반대로 HTTP를 사용하면 순위 성능이 약간 저하됩니다.

그러나 그것이 SSL 인증서를 받고 HTTPS 호스팅으로 전환해야 하는 유일한 이유는 아닙니다.

HTTPS도 더 빠르다는 사실을 알고 계셨습니까?

사이트가 HTTPS 모드(암호화)에서 실행 중이면 웹 브라우저 소프트웨어는 최신 HTTP2 프로토콜(호스트가 지원한다고 가정)을 사용하며, 이는 이전 HTTP 1.1 프로토콜보다 훨씬 빠릅니다.

실제로 HTTPS를 사용하면 사이트에서 14.3% 더 빠르게 다운로드할 수 있습니다.

너무 초라하지!

현재 웹 호스트에서 서둘러 HTTPS로 전환하기 전에 많은 저렴한 호스팅 제공업체가 여전히 HTTP2를 지원하지 않는다는 점을 고려하십시오.

그렇지 않은 경우 인프라가 오래되었다는 확실한 표시이며 Cloudways, WP Engine 또는 Kinsta와 같은 프리미엄 호스팅 회사로 이동해야 하는 또 다른 이유입니다.

프로 팁: HTTPS 암호화 협상 속도를 더욱 높여주는 Cloudflare의 0-RTT(왕복 시간 제로) 기능을 구독하십시오!

(10). 웹사이트에서 허용하는 가장 높은 버전의 PHP 사용(그리고 더 빠른 처리 시간 확보)

PHP는 Joomla, Drupal 및 WordPress와 같은 인기 있는 CMS에서 사용하는 프로그래밍 언어입니다.

믿거나 말거나 웹사이트 5개 중 4개에서 사용하는 코드베이스입니다.

PHP의 좋은 점 중 하나는 보안 강화와 성능 향상을 위해 지속적으로 업데이트된다는 것입니다.

사실, PHP의 새 버전은 약 6-12개월마다 릴리스되며, 각각의 새 PHP 업데이트는 일반적으로 이전 버전보다 10-30% 더 빠릅니다.

각 버전은 한 번에 처리할 수 있는 데이터베이스 요청 수가 증가하여 이전 버전보다 빠르게 작동합니다.

예를 들어, PHP 7.3과 PHP 5.6을 비교하면 최신 버전은 초당 3배 더 많은 트랜잭션을 처리할 수 있습니다.

사이트가 WordPress에 있는 경우 사이트를 최신 PHP 버전으로 업데이트하는 것은 쉬운 결정입니다.

이미 언급한 것과 같은 전문 호스팅 제공업체는 PHP 버전을 자동으로 업데이트합니다.

또는 WordPress의 도구 메뉴에서 사이트 상태 설정을 확인할 수 있습니다. 거기에서 실행 중인 PHP 버전이 표시됩니다.

그리고 그에 따라 업데이트할 수 있습니다.

(11). 비디오용으로 이 서비스를 사용하십시오 – 웹사이트 속도를 크게 향상시킬 것입니다

부정할 수 없습니다. 동영상은 청중을 참여시키는 매우 좋은 방법입니다.

그러나 문제는 로드하는 데 엄청난 양의 서버 리소스를 차지한다는 것입니다.

그리고 배우기 시작하면서 페이지 속도가 더 빨라지기 때문에 서버에 대한 부담이 적을수록 더 좋습니다.

그래서 영상의 경우...

사이트에서 동영상을 자체 호스팅하는 대신 YouTube, Vimeo 또는 Wistia와 같은 독립형 동영상 호스팅 서비스를 사용하세요.

그런 다음 내장 코드를 사용하여 웹사이트에 비디오를 추가합니다.

이렇게 하면 서버가 무거운 비디오 파일을 로드하지 않고 페이지의 다른 요소를 처리하는 데 시간을 사용할 수 있습니다.

그러나 이러한 각 서비스 중 어느 것이 더 낫습니까?

WP Rocket에 따르면 Vimeo는 YouTube 및 Wistia보다 약간 빠르며 가장 느린 플레이어인 Daily Motion보다 훨씬 빠릅니다.

그래도 이 상위 3개 간의 차이는 미미하므로 대부분의 비디오에 Wistia를 선택합니다.

그것은 뛰어난 분석을 가지고 있으며 SEO를 위한 훌륭한 기능인 비디오 사이트 맵을 지원합니다.

(12). 3XX 리디렉션 찾기(및 수정)

301 및 302 리디렉션이 유용합니다.

중복 페이지를 대체 작업 URL로 리디렉션하는 데 사용됩니다.

문제는 페이지 속도가 형편없다는 것입니다.

왜요?

사용자가 3XX 상태 코드 페이지에 액세스하려고 할 때마다 서버에 두 가지 요청이 이루어지기 때문입니다.

하나는 원래(리디렉션된) URL용이고 다른 하나는 최종 도착 URL용입니다.

이는 웹사이트 로딩 시간이 크게 증가함을 의미할 수 있습니다.

하지만 여기에 문제가 있습니다 ...

3XX 리디렉션을 완전히 없앨 수는 없습니다. 그것은 당신의 SEO에 막대한 피해를 줄 것입니다.

그러나 불필요한 3XX 상태 코드를 최소화할 수 있습니다.

(ㅏ). 내부 리디렉션

내부 리디렉션은 해당 페이지를 가리키는 내부 링크가 있는 페이지가 다른 페이지로 리디렉션될 때 발생합니다.

예를 들어:

홈페이지에서 케토 다이어트에 대한 기사 링크(예: healthyfitness.com/keto-diet/)

나중에 해당 주제에 대한 새 기사를 만들고 이전 기사를 새 기사로 리디렉션하기로 결정했습니다. (301은 healthyfitness.com/keto-diet/에서 healthyfitness.com/new-keto-diet/로 리디렉션됨)

잘했습니다. SEO를 위한 좋은 방법입니다.

문제는 홈페이지에 삽입한 내부 링크가 이제 불필요한 "홉"을 거치고 사용자에게는 작동하지만 해당 링크를 따라가는 사람들에게 추가 로드 시간이 추가된다는 것입니다.

다행히도 쉽게 수정할 수 있습니다. 출발지 링크를 최종 도착 URL로 업데이트하기만 하면 됩니다.

사이트에서 리디렉션을 찾는 간단한 방법은 내 링크 확인을 설치하는 것입니다. 이 브라우저 확장 프로그램은 페이지를 크롤링하고 리디렉션되는 링크를 강조 표시합니다.

SEO Sherpa 홈페이지를 빠르게 스캔하면 바닥글에서 여러 내부 리디렉션을 식별할 수 있습니다.

내가 해야 할 일은 WordPress에 로그인하고 해당 바닥글 링크를 최종 목적지로 업데이트하는 것입니다.

(비). 리디렉션 체인

리디렉션은 로드 시간에 좋지 않지만 체인에 있을 때는 훨씬 더 나쁩니다.

리디렉션 체인은 리디렉션된 페이지가 다른 리디렉션된 페이지로 리디렉션될 때 발생합니다.

일반적으로 시간이 지남에 따라 사이트가 변경된 결과입니다.

예를 들어:

• domain.com/about/ 업데이트 및 301 리디렉션:
• domain.com/about-us/ 업데이트 및 301 리디렉션:
• domain.com/about-our-company/ 업데이트 및 301 리디렉션:
• domain.com/company-history/

이제 원본 페이지에 액세스하려는 사람은 한 번이 아니라 세 번 리디렉션됩니다.

나는 리디렉션 체인을 찾기 위해 Ahrefs 사이트 감사를 사용하는 것을 좋아합니다. 사이트를 크롤링한 후 다른 오류와 함께 발생한 리디렉션 체인 문제의 수를 식별합니다.

리디렉션 체인 목록을 자세히 살펴보고 발생하는 체인을 확인할 수 있습니다.

각 체인을 수정하려면 최종 목적지에 대한 절대 링크를 사용하여 원본 URL에서 301 리디렉션을 업데이트하여 중간에 리디렉션 체인을 제거합니다.

(13). 404 오류 제거

그것은 일어난다!

파일이 이동(또는 누락)되고 링크가 끊어집니다.

이 경우 사용자는 누락된 파일을 찾기 위한 추가 웹 서버 요청으로 인해 더 긴 페이지 로딩 시간을 경험하게 됩니다.

결국 404 오류로 이어집니다.

이러한 오류의 원인은 많고 중요하지 않습니다.

당신이 알아야 할 것은 그것들을 찾는 방법뿐입니다:

한 가지 방법은 Google Search Console을 사용하여 검색하고 복구하는 것입니다.

GSC 계정에 로그인하면 적용 범위를 클릭한 다음 오류를 클릭합니다.

제출된 URL을 찾을 수 없음 을 클릭하면 404 오류가 발생하는 모든 링크 목록이 표시됩니다.

또는 Ahrefs 또는 Screaming Frog와 같은 사이트 감사 도구를 사용할 수 있습니다.

어떤 도구를 사용하든 404페이지 및 미디어 파일에 대한 링크를 식별해야 합니다.

그런 다음 끊어진 링크를 교체하거나 제거합니다.

그렇게 하면 사이트 속도가 빨라집니다.

(14). 축소, 업데이트 및 업그레이드 – 플러그인으로 페이지 속도를 향상시키는 3단계

플러그인과 확장은 적을수록 좋습니다.

대부분의 애드온은 JavaScript와 CSS를 로드합니다.

그리고 이미 지적했듯이 이 두 가지는 웹사이트를 느린 모드로 전환할 수 있습니다.

따라서 가능한 한 플러그인을 제거하고 (절대적으로) 필수적인 것만 사용하는 것이 좋습니다.

사이트의 기능을 껐다가 삭제하는 데 필요하지 않은 것은 무엇이든 됩니다.

물론 일부 플러그인은 다른 플러그인보다 사이트 속도에 더 많은 영향을 미칩니다.

따라서 플러그인이 절대적으로 필요하더라도 더 빠른 대안이 있을 수 있습니다.

ServeBolt의 이 게시물은 로드 시간 성능에 가장 영향을 미치는 WordPress 플러그인을 나열하고 더 좋고 더 빠른 옵션을 나열합니다.

더 빠른 대안을 찾으면 전환해야 합니다.

플러그인을 통해 웹사이트 속도를 높이는 세 번째 단계는 최신 플러그인 버전을 실행하고 있는지 확인하는 것입니다.

매우 자주, 이전 플러그인은 현재 버전의 WordPress 또는 PHP와 호환되지 않습니다.

These incompatibilities almost always impact page speed performance.

Thankfully, the plugin menu in WordPress makes it easy to spot outdated plugins:

From there, you can simply upgrade to the latest version.

(15). Use This Little Known Google Tag Manager Trick to Speed up Your Website

You've probably heard of Google Tag Manager? And, hopefully, you are using it on your website.

Google Tag Manager is a container for all your pixels and tracking scripts, which makes deploying codes simple – and bypasses the need for a developer.

Simply moving your tracking pixels from embedded in your website code to Google Tag Manager can shave up to 2 seconds off your load time.

This is a great page speed improvement, but it doesn't stop there…

Did you know that Google Tag Manager, allows you to control when your tags are fired and thus speed up your load times even further?

As you've learned already, any code that's not required for a fast largest contentful paint should be delayed until after the main content has loaded.

By default, Google Tag Manager will fire your tags on page view.

But, by selecting the 'Window Loaded” trigger your tags are fired once the entire content of the page has been fully loaded, including any embedded resources such as images and scripts.

I set this up on the SEO Sherpa website, and because I have a bunch of tracking set up, it boosted load times significantly.

To implement this page speed trick on your own website, login to GTM and select 'New Trigger' and then 'Window Loaded.'

And once you've done that, you're done.

What Did You Think?

Now I'd like to hear from you:

Which technique from today's post are you going to implement first?

Are you going to fix broken links? Or implement lazy loading?

Either way, let me know by leaving a comment below.