웹 사이트 또는 앱이 처음에 얼마나 빨리 로드되는지는 사용자가 받는 첫인상입니다. 이 가이드에서는 초기 페이지 로드에서 귀중한 시간을 단축하는 입증된 기술을 나열합니다.
목차
초기 로드 시간
사용자 또는 고객이 웹사이트 도메인 이름을 입력한 후 콘텐츠를 볼 때까지 걸리는 시간은 좋은 첫인상을 남기는 데 가장 중요한 몇 초입니다.
Amazon은 100밀리초의 대기 시간마다 매출에서 1%의 비용이 든다는 사실을 발견했습니다.
그럼에도 불구하고 많은 웹 개발자는 이것을 나중에 생각하는 것으로 취급합니다. 점점 더 많은 기능을 위해 점점 더 많은 라이브러리가 추가되고 점차 시간이 지남에 따라 변환이 줄어들기 시작합니다. 설상가상으로 이러한 전환 손실은 지표를 보낼 시간이 있기 전에 느리게 로드되는 페이지를 이탈하기 때문에 감지하기 어렵습니다.
이들 중 일부는 프런트엔드와 백엔드에서 구현할 수 있는 기술입니다. 어쨌든 웹 앱은 빠르게 로드되어야 합니다.
올바른 측정 추가
가장 먼저 해야 할 일은 측정값을 추가하는 것입니다. 로드 프로세스에는 여러 단계가 있으며 올바른 세그먼트를 측정하지 않으면 병목 현상이 있는 위치를 알 수 없습니다.
다음은 로드 프로세스의 가장 중요한 이정표입니다.
측정 | 다음에 생성된 다이어그램 테라스트럭트
이것이 의미하는 바는 이 다이어그램의 모든 세그먼트에 대한 지표를 추적해야 한다는 것입니다.
어떻게 할 수 있는지 살펴보겠습니다.
응답에 대한 브라우저 요청 제공:
서버에서 이것을 측정하십시오. API가 응답을 제공할 때 요청을 받는 순간을 얻고 싶습니다. 예를 들어 데이터베이스에 대한 외부 호출이 이루어졌는지 여부에 따라 매우 짧거나 상당한 병목 현상이 발생할 수 있습니다.
받은 응답에 대한 응답:
이것은 측정하기 더 어렵지만 그렇게 하는 한 가지 방법은 응답이 서버를 떠날 때 타임스탬프를 추가하고 가능한 첫 번째 순간에 사용자 측의 현재 시간으로 측정하는 것입니다(HTML 헤드의 스크립트 태그). 페이지).
콘텐츠가 포함된 첫 번째 페인트에 대한 응답:
콘텐츠가 포함된 첫 번째 페인트는 첫 번째 요소가 DOM에서 렌더링되는 시점을 나타냅니다. 텍스트, 배경 또는 로딩 스피너와 같은 간단한 것일 수 있습니다. Chrome 개발 도구에서 Lighthouse를 실행하여 측정할 수 있습니다.
내용이 있는 첫 번째 페인트에서 가장 큰 내용이 있는 페인트까지:
가장 큰 콘텐츠 페인트는 가장 큰 요소가 사용자의 브라우저 뷰포트에서 렌더링되는 시기를 나타냅니다. 이것은 일반적으로 페이지 로드의 “렌더링” 부분의 끝을 알리고 사용자는 채워진 화면을 보게 됩니다. Lighthouse를 실행하여 측정하기도 합니다.
인터랙티브 시간에 가장 큰 콘텐츠가 있는 페인트:
마지막으로 대화형 시간은 사용자가 스크롤, 클릭 및 입력과 같은 작업을 수행할 수 있는 시기를 나타냅니다. 렌더링된 화면이 앞에 표시되지만 할 수 있다고 예상할 때 아무 것도 할 수 없기 때문에 이 기간이 길면 특히 답답할 수 있습니다! 이것은 Lighthouse가 측정하는 데 도움이 되는 또 다른 지표입니다.
코드 줄이기
이제 측정이 완료되었으므로 최적화를 시작할 수 있습니다. 최적화에는 장단점이 있으며 측정을 통해 어느 것이 가치가 있는지 알 수 있습니다.
가장 빨리 로드되는 페이지는 빈 페이지이지만 누군가가 앱과 빈 페이지 사이의 로딩 속도 차이를 알아차리기 전에 앱에 많은 코드를 추가할 수 있습니다. 자주 발생하는 것은 증분이 너무 작아서 하루가 될 때까지 빌드 간 차이를 인식하지 못하고 느리게 느껴지기 시작한다는 것입니다. 당신은 당신의 앱이 부풀려졌다는 것을 깨닫고, 이 시점에서 코드를 줄이는 것이 차이를 만들 것입니다.
코드를 줄이면 속도가 두 가지 향상됩니다.
- 앱이 네트워크를 통해 더 빠르게 전송됩니다.
- 사용자의 브라우저는 코드 구문 분석을 더 빨리 완료합니다.
첫 번째 속도 향상은 작습니다. 요청이 유선을 통해 압축되기 때문에 1MB의 소스 코드를 자르면 대역폭에서 10KB만 절약할 수 있습니다. 그러나 더 적은 구문 분석으로 인한 속도 향상은 중요합니다. 귀하의 사용자는 아마도 전체 범위의 브라우저와 컴퓨터에서 귀하의 앱을 실행하고 있을 것입니다. 그들 중 다수는 귀하가 하는 것만큼 빠르게 코드를 구문 분석할 수 있는 컴퓨팅 성능이 없습니다.
또는 컴퓨팅 성능이 훨씬 낮은 모바일 장치에서 실행될 수 있습니다. 그 차이는 초 단위일 수 있습니다.
따라서 코드가 적을수록 브라우저가 더 빨리 구문 분석을 완료하고 앱을 실행할 수 있습니다. 자바스크립트가 제어하는 로딩 화면을 보여주고 싶어도 해당 코드의 파싱이 선행된다.
그러나 기능을 잘라내거나 실제로 코드를 삭제하고 싶지는 않습니다. 운 좋게도 그렇게 하지 않고도 코드를 줄일 수 있는 몇 가지 표준 사례가 있습니다.
- 축소기를 통해 코드를 실행합니다. 축소기는 긴 이름을 짧은 이름으로 줄이고(signUpDarkModeButton이 ss가 됨), 공백 문자를 제거하는 등의 최적화를 수행하여 아무 것도 잃지 않고 코드를 최대한 간결하게 만듭니다.
- 부분 가져오기. 도서관은 종종 필요하지 않지만 우산 패키지 아래 함께 제공되는 것들로 비대해집니다. 유틸리티 라이브러리의 특정 기능만 원할 수 있으므로 전체 라이브러리를 가져오는 대신 필요한 코드만 가져올 수 있습니다.
- 트리 쉐이크 데드 코드. 때로는 디버깅 목적으로 코드를 남겨 두거나 더 이상 사용되지 않는 기능을 완전히 정리하지 않고 소스 코드에 있지만 실행되지 않는 경우가 있습니다. Webpack과 같은 JavaScript 도구 체인에는 죽은 코드나 사용되지 않는 종속성을 감지하고 프로덕션 빌드에서 자동으로 제거할 수 있는 도구가 있습니다.
코드를 청크로 분할
전체 앱에서 가능한 한 많은 코드를 줄인 후 이 아이디어를 더 짜내고 초기 로드에 필요한 코드를 줄이는 것에 대해 생각할 수 있습니다.
코드의 20%가 사용자가 몇 번의 클릭 후에만 사용할 수 있는 앱의 일부 기능을 지원한다고 가정해 보겠습니다. 로딩 화면을 표시하기 전에 브라우저가 해당 코드를 구문 분석하는 것은 시간 낭비입니다. 코드를 청크로 분할하면 대화형 시간을 크게 줄일 수 있습니다.
모든 Javascript 파일에 대한 가져오기의 얽힌 종속성 그래프 대신 쉽게 잘릴 수 있는 영역을 식별합니다. 예를 들어 구성 요소가 일부 무거운 라이브러리를 로드할 수 있습니다. 해당 구성 요소를 자체 파일로 분리한 다음 사용자가 해당 구성 요소와 상호 작용할 준비가 된 경우에만 가져올 수 있습니다.
사용 중인 프레임워크에 따라 로딩을 지연할 수 있는 여러 라이브러리가 있습니다. 이렇게 하면 사용자가 초기 로드가 빠르고 모든 후속 상호 작용을 기다려야 하기 때문에 모든 구성 요소를 분리할 필요가 없습니다. 분할할 수 있는 가장 큰 조각을 찾고 거기에서 소스 코드를 분할합니다.
서버 측 렌더링
브라우저가 모든 집중적인 파싱 및 컴파일을 수행하고 Chromebook 및 모바일 장치에 사용자가 있어야 한다는 점을 감안할 때 로드 시간을 줄이는 일반적인 기술 중 하나는 서버가 해당 로드의 일부를 처리하도록 하는 것입니다. 이것이 의미하는 바는 요즈음 대부분의 단일 페이지 앱이 하는 것처럼 빈 페이지를 제공한 다음 Javascript를 사용하여 모든 콘텐츠를 채우는 대신 서버(일반적으로 Node.js)에서 Javascript 엔진을 실행하고 내용을 채울 수 있다는 것입니다. 가능한 한 많은 데이터와 콘텐츠.
귀하의 서버는 사용자의 브라우저보다 훨씬 빠르고 예측 가능합니다. 필연적으로 앱이 대화형이 되려면 여전히 일부 Javascript 코드를 구문 분석해야 합니다. 여전히 서버 측 렌더링은 초기 콘텐츠의 많은 부분을 채울 수 있으므로 사용자가 페이지를 가져오면 이미 로딩 화면이나 진행률 표시줄이 최소한으로 표시되고 있습니다.
그리고 초기 보기에 데이터가 필요한 경우 클라이언트는 데이터를 얻기 위해 별도의 요청을 할 필요가 없습니다. 클라이언트가 사용할 수 있도록 앱에서 이미 수화됩니다.
자산 압축
자산은 페이지에 생명을 불어넣고 해당 자산의 렌더링이 완료될 때까지 페이지가 완전히 로드된 것처럼 느껴지지 않습니다. 이것은 배경, 사용자 인터페이스 아이콘, 사용자 프로필 사진, 로딩 스피너일 수 있습니다. 종종 자산은 레이아웃도 바꿀 수 있으므로 사용자가 무언가와 상호 작용을 시도하기 시작하면 자산이 로드되는 동안 페이지가 계속 이동할 수 있습니다. 때때로 이러한 자산은 가장 큰 콘텐츠가 포함된 페인트입니다.
그러나 자산은 앱에서 가장 무거운 부분 중 하나이기도 합니다. 이미지는 몇 메가바이트에 달할 수 있으며 많은 아이콘을 로드하면 브라우저의 최대 동시 네트워크 요청 제한을 쉽게 초과하여 막대한 로드 대기열이 발생할 수 있습니다.
인터넷에서 이미지를 다운로드한 다음 앱에서 참조하는 것은 거의 원하지 않습니다. 이미지는 표시될 수 있는 가장 작은 크기로 크기를 조정해야 합니다. 크기를 조정하지 않고 작은 50픽셀 x 50픽셀 요소로 표시되는 사용자 프로필이 있는 경우 앱은 바탕 화면 배경 무늬처럼 선명하게 보이는 전체 이미지를 다운로드한 다음 작은 크기로 크기를 조정하는 데 시간이 걸립니다.
둘째, 이미지는 형식에 따라 압축될 수 있습니다. 요즘에는 webm이 선호되는 형식이지만 웹의 압축 분야는 지속적으로 개선되고 있으며 많은 새로운 형식이 등장할 예정입니다. 형식의 변화로 인해 일부 브라우저는 최신 형식을 지원하지 않을 수 있습니다! 다행스럽게도 브라우저 기술은 사용자의 브라우저가 지원하는 형식을 로드할 수 있도록 합니다.
따라서 최고의 최신 형식으로 압축하되 덜 현대적인 버전도 유지하고 폴백 형식을 지원하는 사진 및 동영상 요소를 사용하세요.
결론
다음은 사용자가 앱을 매우 빠르게 처음 로드할 수 있도록 하는 가장 효과적인 5가지 기술입니다. 이는 SEO가 빠른 로드 시간을 보상하므로 전환율, 사용자 만족도 및 검색 순위를 향상시킵니다. ~에 테라스트럭트이러한 기술 등을 사용하여 사용자가 이 문서에서 보는 다이어그램을 가능한 한 빨리 만들고 볼 수 있습니다.