웹 사이트 속도 향상: 99% 성능 등급 달성(30부터!)

'2018년에 Google는 페이지 신속성이 이제 데스크톱과 모바일 검색 결과 모두의 순위에 영향을 미칠 것이라고 밝혔습니다. 그러나 페이지 속도의 영향을 받는 것은 위치만이 아닙니다. 연구에 따르면 3초의 페이지 로딩 시간은 13%의 이탈률로 이어지며, 이는 페이지 속도가 검색 결과뿐만 아니라 사용자 경험에도 영향을 미친다는 것을 의미합니다.

그렇다면 웹사이트가 느려지면 어떻게 해야 할까요? 웹사이트 성능을 향상시키는 것은 쉬운 일이 아닙니다. 따라서 많은 회사는 검색 결과에서 자신의 위치를 보장하기 위해 사소한 최적화만 수행합니다.

우리가 어떻게 성과 등급을 30에서 99로 전환했는지, 그리고 왜(우리의 성취에 대해 믿을 수 없을 만큼 자랑스러울 뿐만 아니라) 해당 분야에서 가장 빠른 웹사이트 중 하나를 소유하는 것이 헌신할 가치가 있는지 알아보십시오.

시작: 문제 해결의 장애물과 필요성

웹사이트를 개편함으로써 우리는 세 가지 주요 목표를 달성하는 데 중점을 두었습니다.

1. 신속한 페이지 로딩, 개선된 UX, 최고 수준의 콘텐츠를 통해 전환율을 높입니다.
2. SEO를 강화하고 검색 엔진에서 더 나은 가시성을 확보합니다.
3. 새로운 프로젝트와 고객 리뷰를 선보임으로써 브랜드 이미지를 향상시킵니다.

이러한 목표는 통합에 필요한 기능을 결정하는 데 도움이 되었습니다. 우리의 목표를 실현하기 위해 생각해낸 핵심 기능은 다음과 같습니다.

• 당사의 서비스, 부문, 기술 및 사례 연구를 전시하기 위해 인상적인 외관을 갖춘 참신하게 구성된 웹 페이지입니다.
• 검색 기능, 태그 및 카테고리를 갖춘 향상된 블로그 게시물 페이지.
• 편리한 의사소통을 위한 '연락처' 및 대체 양식입니다.
• 다양한 타사 통합: Google Tag Manager, Cookiebot 및 Hubspot 등.

전반적으로 우리의 목표는 안전한 정적 웹사이트를 구축하는 것이었습니다. 따라서 우리는 이러한 목표에 완벽하게 부합하는 React 프레임워크인 GatsbyJS를 선택했습니다.

왜 개츠비인지 물어보시나요? 근본적인 힘 @GatsbyJS 컴파일 중에 미리 구축된 HTML, CSS 및 JavaScript를 조화시켜 웹 개발을 원활하고 빠른 프로세스로 전환하는 기능에 있습니다. React로 구축된 GatsbyJS를 통해 React 생태계의 확장 기능을 활용하여 개별 템플릿과 구성 요소를 만들 수 있었습니다.

개편된 웹사이트에서 주목을 요하는 또 다른 측면은 API 백엔드였습니다. 우리의 선호는 @스트라피, 오픈 소스 콘텐츠 관리 시스템. 이 시스템을 통해 데이터 구조를 맞춤화하고 텍스트, 이미지, 비디오와 같은 다양한 콘텐츠 형식을 관리하기 위한 API 기능을 확장할 수 있었을 뿐만 아니라 사용자 친화적인 관리 패널과 추가 기능 덕분에 상당한 시간과 리소스를 절약할 수 있었습니다. 모든 것을 처음부터 개발할 필요성을 우회한 것입니다.

마지막으로 서버 요청의 경우 GraphQL을 활용했습니다. GatsbyJS와 원활하게 호환되므로 쿼리 형식을 정의하고 필수 필드와 관계만 지정할 수 있으므로 불필요한 데이터를 피하여 페이지 로딩 시간이 더 빨라졌습니다.

기술의 융합을 통해 우리는 최적의 웹사이트 안정성과 보안을 달성할 수 있었습니다.

완료되자 새로운 웹사이트가 모습을 드러내며 순위가 높아지고 디자인이 새로워졌습니다. 처음에는…그러나 이후에는 상황이 점차 악화되기 시작했습니다. 새 페이지 추가, 일련의 수정 및 타사 소프트웨어 통합에 따라 코드베이스는 웹 페이지 속도 분석 도구인 Google의 Lighthouse에 대한 성능 등급이 크게 떨어질 정도로 성장했습니다.

The Lighthouse는 개선 노력을 시작하기 전에 당사 웹사이트가 보유하고 있는 점수를 평가합니다.

이렇게 감소된 점수로 인해 Google는 우리에게 유리한 위치를 차지하지 못할 것입니다. 게다가, 그렇게 하더라도 사용자는 로드될 때까지 기다리지 않을 것입니다.

Ericsson의 연구 모바일 장치에서 페이지 로딩 지연으로 인한 부담은 공포 영화를 보는 것과 비슷하다는 것을 보여주었습니다. 매 순간이 성능 측면에서 중추적인 역할을 합니다. 이러한 어려움을 이해하고 우리는 즉시 사이트 성능을 개선하기 위해 노력했습니다.

웹사이트 효율성을 체계적으로 향상

주목할 만한 성능 향상을 달성하기 위해 우리는 웹 사이트를 괴롭히는 주요 문제를 면밀히 조사하고 각 문제를 해결하기 위한 노력을 시작했습니다. 아래에서는 우리가 주요 과제를 어떻게 극복했는지 설명합니다.

1. 네트워크 연결 설정 속도를 두 배로 향상

GMetrics웹 사이트 로딩 패턴을 기술하는 도구인 는 연결 시간 연장의 원인이 되는 외부 도메인의 리소스를 정확히 찾아내는 데 도움이 되었습니다.

보라색 타이밍은 도메인 이름 서버가 도메인 이름의 IP 주소에 대한 요청을 수신하는 데 걸리는 시간을 나타내고 밝은 녹색은 서버 연결 시간을 나타냅니다. 이러한 간격이 길어짐에 따라 서버 연결 시간을 억제하여 신속하게 처리했습니다.

웹사이트의 신속한 처리를 위해 다양한 기술적 개선 사항을 구현했습니다. 처음에는 HTML을 활용하여 리소스 힌트를 배포했습니다. <link> 속성. 이러한 힌트는 리소스 요청이 서버에 전달되기 전에 브라우저가 사전에 연결을 설정하는 데 도움을 줍니다. 외부 도메인의 리소스의 경우 DNS 프리페치 및 사전 연결 힌트를 통합하여 지정된 도메인과의 연결을 시작하도록 브라우저에 미리 지시했습니다. 따라서 브라우저가 외부 도메인의 리소스를 필요로 하는 경우 예비 설정이 이미 완료되었으므로 해당 리소스가 신속하게 로드됩니다.

스크립트 및 스타일시트와 같은 내부 파일과 관련하여 "미리 로드" 및 "프리페치" 힌트를 사용했습니다. 이러한 신호는 사용자가 당사 사이트의 페이지를 탐색할 때 필수 리소스를 로컬 캐시에서 가져오도록 하여 원격 서버에서 해당 리소스를 검색할 필요가 없도록 하여 프로세스를 가속화합니다.

이러한 최적화를 통해 *콘텐츠가 포함된 가장 큰 페인트는 2.9초에서 0.8로, *콘텐츠가 포함된 첫 번째 페인트는 1초에서 0.6초로 줄어들어 브라우저에서 리소스 로딩을 가속화할 수 있었습니다.

*LCP, 에필수 웹 바이탈 측정 이는 사용자가 페이지 로딩을 시작한 때부터 가장 눈에 띄는 이미지가 뷰포트에 나타날 때까지의 기간을 수량화합니다.

*FCP는 사용자가 페이지에 처음 액세스한 시점과 콘텐츠가 화면에 렌더링되는 시점 사이의 간격을 나타냅니다.

빠른 텍스트 렌더링으로 글꼴 로딩 향상

우리 플랫폼 내에서는 개인화된 글꼴과 공개적으로 사용 가능한 글꼴을 혼합하여 사용합니다. 우리는 Google부터 공개 글꼴 “Manrope”를 호스팅합니다. 글꼴 소스 컬렉션은 글꼴을 얻는 가장 빠른 접근 방식을 나타냅니다.

그럼에도 불구하고 HTML 파일에서 텍스트를 검색했음에도 불구하고 글꼴 패키지를 로드하는 데 지연이 발생했습니다. 텍스트와 글꼴 로딩 사이의 이러한 불일치를 피하기 위해 우리의 초기 전략은 선호하는 웹 글꼴이 완전히 로드될 때까지 가려진 대체 글꼴을 표시하는 것이었습니다. 이 방법은 효과적이기는 했지만 LCP 측정항목을 늘려 신속한 텍스트 렌더링을 위해 전략을 조정하게 만들었습니다.

작업 흐름은 다음과 같습니다. 처음에 브라우저는 지정된 글꼴 모음 내에서 액세스 가능한 글꼴을 식별하고 텍스트 렌더링을 위해 배포합니다. 이후 원본 글꼴을 로드하면 브라우저는 초기 글꼴을 필요한 글꼴로 원활하게 대체합니다. 이 전략은 글꼴 크기 변경으로 인해 예기치 않은 텍스트 이동의 위험이 있지만 가장 빠른 글꼴 로딩 방법입니다. 레이아웃 변경을 완화하고 누적 레이아웃 변경(CLS, 페이지 로딩 중 예상치 못한 요소 변경을 추적하기 위한 게이지)을 개선하기 위해 우리는 CSS 글꼴 모듈 레벨 5, 다음과 같은 속성을 포함하는 사양 모음입니다. 사이즈 조정, 하강 오버라이드, 그리고 라인 갭 오버라이드, 이는 콘텐츠 이동을 방지하는 데 도움이 되었습니다.

CSS 글꼴 모듈 레벨 5는 레이아웃에 영향을 주지 않고 글꼴 변경을 보장하면서 완벽하게 수행되었습니다.

결과적으로, 콘텐츠가 포함된 첫 번째 페인트, 콘텐츠가 포함된 최대 페인트, 누적 레이아웃 이동이라는 세 가지 지표가 향상되었습니다. 특히 CLS는 0,143초에서 0초로 단축됐다.

사진 및 비디오 로딩 향상

우리가 직면한 또 다른 성능 문제는 상당한 네트워크 페이로드였습니다. 웹사이트 감사에서는 품질 저하 없이 크기를 줄여 이미지와 비디오의 로딩 프로세스를 간소화해야 한다는 사실을 밝혀냈습니다.

노란색 실험실 도구 평가에 따르면 비디오와 이미지는 모든 파일 형식 중에서 당사 웹사이트에 상당한 부담을 주는 것으로 나타났습니다.

당사 웹사이트는 벡터 이미지(SVG(Scalable Vector Graphics) 형식)와 래스터 이미지(PNG 및 JPG 형식)의 두 가지 이미지 변형으로 구성됩니다. 각 category에 대해 서로 다른 최적화 기술이 사용되었습니다.

3.1 벡터 이미지의 향상

벡터 이미지는 일반적으로 가벼운 특성을 자랑합니다. 그러나 각 이미지를 로드하기 위해 새로운 HTTP 요청이 필요하여 성능이 저하될 때 문제가 나타났습니다. 이 문제를 해결하기 위해 우리는 이미지를 HTML에 직접 삽입할 수 있는 인라인 SVG 채택을 선택했습니다. 이는 다음을 통해 촉진되었습니다. '개츠비-플러그인-반응-svg' , 프로세스를 간소화하는 Gatsby 프레임워크 내의 플러그인입니다.

3.2 래스터 이미지 향상

PNG 및 JPG 이미지의 로딩 속도를 높이기 위해 최신 .webP 형식으로 전환하여 품질 저하를 최소화하면서 뛰어난 압축을 보장합니다. 마찬가지로, 비디오 변환이 .mp4에서 .webM으로 수행되어 향상된 압축 및 품질이 보장되었습니다. .webP 및 .webM이 주요 형식으로 채택되었지만 이전 브라우저 버전과의 호환성 문제가 예상되었습니다. 이를 완화하기 위해 .webP 및 .webM에 대한 지원이 부족한 브라우저에 대해 .png, .jpg 및 .mp4 형식으로의 대체가 유지되었습니다.

게다가 이미지 디스플레이는 다양한 장치에 걸쳐 최적화가 필요했습니다. 모바일, 태블릿, 노트북, 4K 모니터 등 다양한 장치에는 고유한 이미지 크기가 필요했습니다. 모바일과 4K 모니터 모두에 동일한 이미지를 업로드하면 웹사이트 로딩 시간이 늘어났습니다. 이에 대한 해결책으로 우리는 브라우저가 창 크기, 화면 해상도, 네트워크 속도 등과 같은 요소를 기반으로 최상의 이미지를 선택할 수 있도록 코드에 다양한 이미지 옵션을 포함하는 적응형 그래픽을 구현했습니다. 다음과 같은 패키지를 활용하여 '개츠비 배경 이미지' 그리고 '개츠비 이미지' , 우리는 개별 장치에 맞게 조정된 여러 이미지 변형을 만들었습니다. 에서 네트워크 탭 아래 스냅샷을 보면 페이지 표시 모드 간을 전환한 "장치 전환 도구 모음"이 표시됩니다.

여기서는 다양한 장치에 대한 이미지 로딩을 개선하기 위해 장치 도구 모음을 활성화했습니다.

여기에는 크기가 축소된 다양한 장치에 최적화된 동일한 파일이 표시됩니다.

3.3 비하인드 이미지를 위한 지연 로딩

마지막으로, 사용자가 이미지를 볼 때만 이미지 로딩을 보장하기 위해 흐릿한 이미지 효과와 결합된 지연 로딩을 구현하여 제한된 사용자의 경험을 풍부하게 했습니다.

가격 책정 일정 또는 느린 인터넷 연결.

이는 시각적 콘텐츠의 지연 로딩 기능이 어떻게 작동하는지를 보여줍니다.

모든 어려운 노력이 성과를 거두었습니다. 품질 저하 없이 웹 사이트의 시각적 크기를 눈에 띄게 줄였습니다.

향상된 결과에도 불구하고 Yellow Lab Tools는 비디오가 페이지 무게에서 여전히 더 큰 부분을 차지하지만 시각적 요소의 로드가 크게 감소했음을 보여줍니다(보라색 부분).

향상된 기능으로 인해 CLS 및 LCP와 같은 사용자 경험과 게이지가 상당히 풍부해졌습니다. Gatsby 생태계 내에서 시각적 최적화 확장 기능을 독점적으로 활용하여 성능 향상 프로세스를 촉진했습니다.

4. 캐싱 간소화

웹 서버가 웹 페이지의 복사본을 유지하는 방법인 캐싱은 웹 사이트 생성 과정에서 처음에는 무시되었다는 점을 인정해야 합니다. 효과적인 캐싱을 통해 웹사이트 속도를 높이고 서버 부담을 줄일 수 있다는 점에서 이는 부인할 수 없는 전망이었습니다. 우리는 캐시 최적화를 따라잡기로 결심했지만 다양한 특정 장애물에 직면했습니다.

우리의 목표는 리소스를 매번 다운로드하는 대신 향후 방문을 위해 저장해 두어 리소스 로드를 가속화하는 것이었습니다. 이를 달성하기 위해 우리는 HTTP 헤더에 'cache-control' 속성을 사용하고 파일이 캐시에 유지되어야 하는 기간을 설정했습니다. 그러나 또 다른 난관이 드러났다. 웹 사이트 콘텐츠나 디자인을 수정해도 브라우저가 이전에 저장된 복사본을 계속 활용하기 때문에 변경 사항이 즉시 표시되지 않습니다.

어떻게 해결했나요? 파일 이름에 해시를 추가하여 파일을 편집할 때마다 새로 고쳐집니다. 이 접근 방식을 통해 우리는 캐시에 파일을 장기간 동안 보존하는 동시에 손쉽게 변경 작업을 수행할 수 있었습니다. 그 결과, 첫 번째 콘텐츠가 포함된 페인트(FCP) 측정항목이 높음에서 보통으로 전환되었습니다.

현재 우리는 브라우저 캐싱이라는 추가적인 캐싱 형태를 고려하고 있습니다. 지속적인 서버 연결이 필요하고 응답을 로드하기 위해 대역폭을 소비하는 서버 캐싱과 달리 브라우저 캐싱을 사용하면 사용자는 네트워크 연결 없이 웹 페이지에 액세스할 수 있습니다. 그럼에도 불구하고 여기에는 제약이 따릅니다. 즉, 사용자 장치의 저장 공간이 부족한 경우 브라우저는 새 콘텐츠를 수용하기 위해 오래된 데이터를 삭제할 수 있습니다.

더 나은 이해를 제공하기 위해 다음은 서버 측 캐싱과 클라이언트 측 캐싱 기능을 병치한 것입니다.

5. 상당한 JavaScript 컬렉션 근절

번들은 기본적으로 파일(일반적으로 JavaScript, CSS 및 기타 속성)로 구성되며 보다 효과적인 배포를 위해 통합 파일로 통합됩니다. 우리 웹사이트가 복잡해짐에 따라 번들의 크기가 지속적으로 확장되어 웹사이트에 과중한 부담이 생겼습니다. 문제가 있는 부분을 정확히 찾아내고 폐기하는 것이 적절한 시점이었습니다.

문제가 있는 번들을 인식하고 수정하는 데 유용한 여러 가지 도구를 사용할 수 있습니다. 그들 중 하나, 번들공포증, NPM 패키지가 번들 크기에 얼마나 기여하는지에 대한 통찰력을 제공하여 지나치게 큰 파일 컴파일을 피하는 데 도움이 됩니다. 수입 비용VSCode 확장인 은 가져온 패키지의 '비용'을 계산하여 정보에 입각한 결정을 내리는 데 도움을 줍니다. 최적화 전략의 일환으로 널리 사용되는 '클래스 이름' 패키지를 더 효율적인 패키지로 대체하는 등 무거운 JS 라이브러리를 대체했습니다. 'clsx', 당사 웹 사이트 요구 사항에 맞게 조정된 더 빠르고 더 작은 드롭인 교체입니다.

이후에는 웹팩 번들 분석기 플러그인을 사용하여 번들에서 문제가 있는 부분을 정확히 찾아냈습니다.

Bundle analyzer는 가장 중요한 번들인 클라이언트 위치 및 깜박이는 점이 있는 지도를 공개했습니다.

이러한 복합 파일을 분석하기 위해 코드 분할 및 지연 로딩을 활용하여 대규모 번들을 더 작은 구성 요소로 분할했습니다. Webpack의 통합 코드 분할 기능을 사용하면 파일을 직접 가져오는 대신 파일 경로를 지정하는 기능으로 가져오기 명령을 수정할 수 있었습니다. 이는 파일이 로드될 것이라는 약속과 유사한 약속을 생성합니다. 코드에 유사한 구조가 나타나면 이 약속이 적용되고 파일이 로드됩니다.

필수적이지 않은 보기, HTML 및 JS의 경우 웹페이지의 초기 크기를 줄일 수 있는 동적 가져오기를 활용했습니다. 이 맥락에서 동적이란 웹사이트가 특정 조건에 따라 보충 파일을 로드할지 여부를 결정하여 사용자 경험을 방해하지 않는다는 것을 의미합니다.

최적화 결과는 다음과 같습니다. 격리된 확장 번들 없이 개선된 로딩 프로세스

상당한 번들을 더 작은 세그먼트로 분할한 후 페이지를 효과적으로 경량화하고 광범위한 파일 컬렉션을 모두 제거했습니다.

6. 코드 압축을 통해 HTML과 CSS 압축

코드 압축은 우리의 접근 방식에 혁명을 일으켰습니다. 코드를 압축하고 불필요한 공간을 생략함으로써 파일 크기 감소, 빠른 다운로드 및 대역폭 사용량 최소화를 달성했습니다. 현재 당사 서버는 웹사이트 파일을 gzip 형식으로 제공하여 속도를 향상시키고 특히 FCP 및 FID(첫 번째 입력 지연, 초기 클릭과 브라우저 응답 사이의 지연을 측정하는 측정항목)와 같은 중요한 측정항목을 차선 성능 수준에서 중간 성능 수준으로 향상시킵니다.

7. 코드 품질 향상 및 메모리 누수 해결

면밀히 조사한 결과, 코드베이스 내에서 몇 가지 교활한 메모리 누수를 발견했습니다. 이 문제는 더 이상 필요하지 않은 개체가 메모리에 남아 있어 혼잡한 환경으로 이어지는 데서 발생했습니다.

이를 해결하기 위해 우리는 두 가지 접근 방식을 구현했습니다. 이벤트 리스너가 한 번만 필요한 경우에는 {only: true} 매개변수를 선택했습니다. 이 매개변수는 리스너가 트리거된 후 자동으로 제거되어 메모리 관련 문제를 완화합니다. 또한, RemoveEventListener() 메서드를 활용하여 이벤트 리스너를 명시적으로 제거했습니다. 이 단계는 요소를 제거하기 전이나 청취자가 더 이상 사용되지 않게 된 후에 수행되었습니다. 이러한 작업을 통해 요소와 기능 간의 원활한 연결 끊김이 촉진되어 메모리 누수를 방지할 수 있습니다.

addEventListener와 관련하여 고려해야 할 또 다른 측면은 {passive: true } 매개변수를 통합하는 것입니다. 이러한 조정은 스크롤 상호 작용, 인터페이스 중단 방지 및 향상된 사용자 경험에 기여하는 데 도움이 되는 것으로 입증되었습니다.

useEffect(() => { setScrolled(document.documentElement.scrollTop > 50); window.addEventListener('scroll', handlerScroll, { Passive: true }); return () => { document.body.style.overflowY = ' 스크롤'; window.removeEventListener('scroll', handlerScroll) }, []);

이전부터 이후까지: 웹사이트 성능 향상이 미치는 영향

솔직히 말해서 우리의 초기 위치는 최적이 아니었습니다. 느린 로딩 시간과 사용자 경험을 심각하게 손상시키는 압도적인 서버 문제로 인해 어려움을 겪었습니다. 그러나 귀중한 통찰력과 최적화 전략을 바탕으로 우리는 해당 작업에 전념했고 인상적인 결과를 얻었습니다. 결과에 만족했나요? 의심할 여지 없이.

PageSpeed 인사이트 상당한 개선 사항을 강조하는 칭찬할 만한 성적표를 우리에게 제시했습니다.

한 달 간의 성과 평가에서는 놀라운 진전이 나타났습니다. 모든 측정항목은 시작점에 비해 여러 가지 개선이 나타났습니다.

이러한 변화는 셀 수 없이 많은 시간과 며칠의 헌신적인 노력이 없었다면 달성할 수 없었을 것입니다. 그러나 우리의 승리에 크게 기여한 또 다른 요인은 적절한 도구의 활용이었습니다. 특정 도구는 우리가 노력하는 동안 시간을 절약해줄 뿐만 아니라 인정받을 가치가 있습니다.

성능 향상을 위한 도구: PageSpeed Insights 및 Lighthouse

성능 평가 및 향상 영역에서 두 가지 Google 유틸리티가 눈에 띕니다. PageSpeed 인사이트 그리고 등대. 이러한 도구는 웹페이지의 다양한 측면을 면밀히 조사하여 속도, 사용자 경험 및 전반적인 성능에 대한 통찰력을 제공합니다. 그들이 종합적으로 평가하는 지표는 다음과 같습니다.

• 콘텐츠가 포함된 최대 페인트(LCP) – 표시 영역에서 가장 큰 콘텐츠 요소(예: 이미지 또는 텍스트 블록)가 사용자에게 표시되는 기간을 측정합니다.
• 첫 번째 콘텐츠가 포함된 페인트(FCP) – 브라우저가 텍스트나 이미지와 같은 초기 콘텐츠를 렌더링하는 데 걸리는 시간을 측정합니다.
• 첫 번째 입력 지연(FID) – 사용자의 기본 상호 작용(예: 버튼 클릭)과 해당 작업에 대한 브라우저의 응답 사이의 지연을 평가합니다.
• CLS(누적 레이아웃 변경) – 페이지 수명 동안 발생하는 모든 개별 레이아웃 변경 점수의 합계를 계산합니다. 페이지에 표시되는 요소가 예기치 않게 이동할 때 레이아웃 변경이 발생합니다.
• 다음 페인트(INP)와의 상호작용 – 페이지의 시각적 콘텐츠를 업데이트하여 브라우저가 사용자 상호 작용(예: 클릭 또는 탭)에 반응하는 시간을 계산합니다.
• 첫 번째 바이트까지의 시간(TTFB) – 요청 후 브라우저가 서버로부터 데이터의 초기 바이트를 수신하는 기간을 결정합니다.
• 총 차단 시간(TBT) – 브라우저의 기본 스레드가 방해를 받아 사용자 입력에 응답할 수 없는 총 기간을 수량화합니다.
• TTI(상호작용 시간) – 페이지가 완전히 대화형이 되는 데 걸리는 시간을 평가합니다. 이는 모든 필수 리소스가 로드되고 페이지가 사용자 입력에 즉시 응답함을 의미합니다.
• FID(첫 번째 입력 지연) – 사용자의 초기 상호 작용과 해당 상호 작용에 대한 브라우저의 반응 사이의 지연을 면밀히 조사합니다.

이러한 도구 중 하나를 활용하여 웹 사이트 성능에 대한 통찰력을 얻을 수 있습니다. Lighthouse는 더 많은 유연성과 자세한 통찰력을 제공하는 반면 PageSpeed Insights는 개별 페이지 성능 모니터링에 중점을 둡니다.

이 두 가지가 눈에 띄게 활용되기는 하지만 이것이 우리 측의 유일한 권장 사항은 아닙니다. 성능 최적화 탐색에 매우 유용할 수 있는 몇 가지 추가 리소스는 다음과 같습니다.

포괄적인 탐색을 위한 보조 도구

GT메트릭스: 페이지를 감사할 뿐만 아니라 쉽게 이해할 수 있는 형식으로 로딩을 시각화하여 성능 향상을 가시화하는 강력한 도구입니다.

노란색 실험실 도구: 수많은 지표를 분류하고 평가하는 통찰력 있는 대시보드입니다. 문제를 식별할 뿐만 아니라 최적화를 위한 자세한 제안도 제공합니다.

이러한 도구는 성능을 향상하고 탁월한 사용자 경험을 제공하는 데 도움이 되는 길잡이 역할을 했습니다. 웹사이트 성능 향상을 시작할 때 이를 염두에 두십시오.

결론

귀하의 비즈니스가 웹사이트에 달려 있다면 웹사이트의 성능을 무시할 수 없습니다. 이러한 측면은 귀하를 Google 검색 결과의 최전선으로 이끌거나 반대로 사용자가 우수한 경험을 제공하는 더 빠른 웹 사이트로 마이그레이션하도록 유도할 수 있습니다. 그러한 곤경을 피하기 위해 우리는 우리 웹사이트의 변화에 대한 이야기를 공유했습니다.

항상 개선의 여지가 있기 때문에 최적의 성능을 추구하는 우리의 여정은 계속됩니다. 최근 우리는 GatsbyJS에서 몇 가지 문제를 발견했으며 NextJS로의 전환을 고려하고 있습니다. 그러나 이러한 심의는 별도의 기사에서 자체 논의가 필요합니다.

두 기업이 서로 같지 않은 것처럼 사이트 성능을 향상시키기 위한 보편적인 청사진도 없습니다. 각 시나리오는 고유하므로 상황에 따른 특정 문제를 해결하기 위한 맞춤형 접근 방식이 필요합니다. 쉬운 작업은 아니지만 우리는 도와드릴 준비가 되어 있습니다. 웹사이트의 성능을 향상시키려는 경우 다음을 수행하십시오. 우리에게 연락해, 그러면 우리가 당신을 위해 무엇을 할 수 있는지 알아보겠습니다.
`