지능형 최적화 기술: React를 사용하여 로드 지연

작성자Kristofer Selbekk
만약 중대형 웹 응용 프로그램에서 일한 적이 있다면, 가방의 크기 (브라우저에 보내는 자바스크립트 코드량) 가 끊임없이 증가하는 괴물이라는 것을 알 수 있을 것이다.라이브러리나 관리자 기능이 추가될 때마다, 응용 프로그램이 불러오기 시작하는 것은 일반 사용자들이 조금 느릴 뿐입니다.노트북에서는 여전히 성능이 좋다고 느낄 수 있지만 수신 효과가 좋지 않은 곳에서 작년 모델의 휴대전화를 사용하는 사람들은 곧 성능이 떨어지는 것을 느낄 것이다.
그러나 주요 문제는 당신이 다운로드한 코드의 총량이 아니라 사용자에게 관심 있는 것을 보여주기 전에 반드시 다운로드하고 해석하고 실행해야 하는 코드의 양이라는 사실이 증명되었다.일부 사용자에게 있어서 이러한 지연은 정말 길 수 있으며, 이것은 틀림없이 당신의 업무 손실 달러로 바뀔 것이다.다시 말하면 투자할 만한 도전이다.
본고는 지연 로드의 개념, 어떻게 React에서 실현되고, 어떤 방법을 사용하며, 언제 최상의 결과를 얻을 수 있는지 소개하고자 합니다.

지연 로드란?

지연 로드란 필요할 때만 코드를 추출하는 기술을 가리키며 필요할 때만 코드를 추출한다.대형 JavaScript 패키지를 다양한 섹션으로 분할할 수 있습니다. 이 기술은 페이지, 섹션 또는 개별 구성 요소의 코드를 포함하는 코드 분할 기술입니다.이 코드가 필요할 때, 서버에 특정한 코드를 요청해서 메모리에 다운로드하고 불러옵니다. 그것이 항상 거기에 있는 것처럼.
응용 프로그램을 몇 부분으로 나누는 것은 자신만의 도전이다.우리가 해결해야 할 도전은 모든 패키지에 무엇을 넣을지, 언제 다운로드할지, 코드 다운로드를 기다릴 때 무엇을 할지 결정하는 것이다.

React의 로드 지연 기초 지식

이러한 코드 버스트가 중요하므로 기본 제공되는 프로세스 지원을 사용하여 다음 예제에서 시작합니다.

import * as React from 'react';
import { Router, Route } from 'react-router-dom';
import LandingPage from './pages/landing-page';

const AdminPage = React.lazy(() => import('./pages/admin-page'));

export const App = () => {
  return (
    <React.Suspense fallback={<Spinner />}>
      <Router>
        <Route path="/" component={LandingPage} />
        <Route path="/admin" component={AdminPage} />
      </Router>
    </React.Suspense>
  );
}

우리는 두 개의 노선 / 과 /admin 을 포함하는 프로그램을 만들고 있습니다.기본적으로 로그인 페이지는 프로그램의 메인 패키지와 묶여 있습니다. (평소와 같이 불러옵니다.)그러나 관리 페이지에서 우리는 서로 다른 일을 했다.
이 줄 React.lazy(() => import('./pages/admin-page')) 은 많은 사람들에게 새로운 문법일 수도 있지만, 자바스크립트에 내장된 지 몇 년이 되었다.지금 벌어지고 있는 일과 사용자 체험에 대한 의미를 빠르게 살펴보자.import('./some/file') 문법은 동적 가져오기라고 하는데 요청 패키지의 특정 부분을 통해 작동한다.이러한 도구는 일반적으로 Webpack이나 Parcel 같은 번들 도구에 태그로 사용되어 더 적은 코드로 더 많은 JavaScript 파일을 출력합니다.React.lazy() 함수는 기본적으로 React에 '일시 정지' 를 알려주고 프로그램의 이 특정 부분이 서버에서 불러오고 해석되기를 기다리고 있습니다.이 일시정지의 개념은 매우 새롭지만, 현재 당신이 알아야 할 것은, 우리가 프로그램을 포장하는 <React.Suspense /> 구성 요소가 코드 다운로드를 기다릴 때 예비 UI를 보일 것이다.
다시 말하면 절차는 다음과 같다.

탐색 프레젠테이션

이것은 듣기에 매우 합리적일 수 있지만, 우리 ademo to see it in practice를 봅시다.
CodeSandbox에서, 우리는 상당히 큰 라이브러리를 사용하는 구성 요소를 타성적으로 불러오고 있습니다.토론 중인 구성 요소에서만 이 라이브러리를 사용하기 때문에, 화면에 표시하려고 할 때까지 라이브러리를 불러올 수 있습니다.
"비싼"구성 요소를 렌더링할 때, 우리는 그것을 <React.Suspense /> 경계에 포장합니다.즉, 구성 요소의 코드 다운로드를 기다리는 동안 대체 UI(예: 마이크로스피커, 뼈대 UI 또는 텍스트 문자열)를 표시할 수 있습니다.
다음은 이 프로세스가 Chrome 개발 도구에 나타낸 것입니다.

패키지 이름 지정

우리가 불러온 가방은 정상적으로 작동할 수 있지만, 그것들의 명칭은 적합하지 않다.0.chunk.js와 1.chunk.js는 이 일을 완성할 수 있지만, 이것은 디버깅 생산 중의 오류에 있어서는 그다지 좋지 않다.
다행히도 블록 이름을 개선할 수 있는 방법이 있습니다.Webpack은 "magic comments"라는 특수 주석 구문을 지원하며 다른 블록의 이름을 지정할 수 있습니다.
우선, 동적 가져오기를 지정하기 위해 App.tsx 파일에 들어갑니다.우리는 이 점을 바꿔야 한다.

const SomeExpensiveComponent = React.lazy(
  () => import("./SomeExpensiveComponent")
);

이 경우:

const SomeExpensiveComponent = React.lazy(
  () =>
    import(
      /* webpackChunkName: "SomeExpensiveComponent" */ "./SomeExpensiveComponent"
    )
);

이제 페이지를 다시 불러올 수 있고 블록 이름이 변경되었음을 알 수 있습니다.

코드 버스트 정책

코드 분할 및 로드 지연 코드는 사용자가 현재 사용하고 있는 응용 프로그램 부분만 로드하기에 적합합니다.그러나 묶어야 할 내용과 불러오는 것을 지연시켜야 할 내용에 대해 한도값을 어디에 설정하셨습니까?
두 가지 주요한 방법이 있는데, 그것들은 모두 각자의 장점과 단점을 가지고 있다.
라우팅 기반 버스트
많은 개발자들이 처음에는 루트를 바탕으로 응용 프로그램을 분리해서 모든 루트(또는 응용 프로그램의 화면)가 자신의 패키지를 가지고 있다.이것은 매우 좋은 방법으로, 많은 노선이 있지만 사용자가 전부 방문하는 경우는 매우 적다.이 개념도 일리가 있다. 왜 사용자가 아직 방문하지 않은 페이지의 코드를 다운로드해야 합니까?
루트 분할 프로그램의 단점은 한 페이지를 훑어보는 즉각적인 느낌을 잃었다는 것이다.우리는 즉시 내비게이션을 하지 않고 백그라운드에서 새 페이지를 다운로드한 후에 사용자에게 표시해야 한다.이것은 여러 가지 기술로 완화할 수 있지만 (예를 들어 사용자가 링크를 멈출 때마다 페이지를 미리 불러오는 것) 정확하게 실행하기는 어렵다.
어셈블리 기반 버스트
일부 개발자들은 대부분의 주요 구성 요소를 자신의 가방으로 나누기로 결정했다.이것은 노선에 기초한 방법을 통해 대부분의 도전을 해결했다. 왜냐하면 노선 자체가 한데 묶여 있기 때문이다.
그러나 이런 방법도 결점이 있다.구성 요소를 게으름 피우며 로드할 때마다 백그라운드에서 로드할 때 백업 UI를 제공해야 합니다.또한 모든 블록은 약간의 비용과 네트워크 지연을 가져오기 때문에 아무것도 하지 않는 것보다 더 느린 체험을 쌓을 수 있다.
이 모든 것은 분열에 기초한 것이다
나의 경험은 이 두 가지 방법을 결합시키고 어떤 특정한 상황에서 어떤 것이 가장 좋은 보답을 가져다 줄 수 있는지를 고려하여 가장 좋은 결과를 얻을 수 있다는 것이다.
하나의 좋은 예는 프로그램을 '로그인 프로그램' 과 '로그아웃 프로그램' (Kent C.Dodds가 authentication in React 에 올린 글로 제공) 으로 나누는 것이다.여기서 응용 프로그램의 거의 겹치지 않는 두 부분 사이를 고급 분할할 수 있습니다.
또 다른 예는 연락처 페이지나 프라이버시 정책 같은 아주 적은 경로를 코드에서 분리하는 것이다.이러한 상황에서 1초를 표시하는 마이크로스피커는 주요 사용자 체험의 일부분이 아니기 때문에 완전히 받아들일 수 있을 것이다.
세 번째 예는 사용자가 등록 흐름에 생일을 입력해야 할 때 날짜 선택기 라이브러리를 사용할 수 있는 아주 큰 구성 요소를 불러와야 하는 경우입니다.대부분의 사용자가 그것을 필요로 하지 않기 때문에, 우리는 예비 UI를 표시하고, 필요한 사용자들을 위해 추가 코드를 불러오기만 하면 된다.
각 시나리오를 고려하여 제공된 차이를 바이트 단위로 측정합니다.많은 구축 시스템 (예:create-react-app) 은 이전 구축과는 다른 패키지 크기와 단일 블록 크기를 제공합니다.시도를 두려워하지 마라. 그러나 성능상의 차이는 더욱 복잡한 균형을 잡을 수 있도록 확보해야 한다.

게으르다.

대부분의 현대 웹 응용 프로그램에 지연 로드를 추가하는 것은 좋은 일일 수도 있다.최종 사용자가 필요로 할 때만 그들에게 더 적은 코드를 보낼 수 있다.이것은 시작하기 쉽다. 특정한 용례에서 어떤 전략을 사용할지 고려하기만 하면 전체 응용 프로그램으로 확장하기 쉽다.

프런트엔드 애플리케이션 모니터링

실패는 항상 오류나 붕괴로 인한 것이 아니지만, 눈치채지 못한 오류나 감속의 결과일 수도 있다.제가 저번에 발표했을 때 소개를 했나요?그것은 백엔드에서 왔습니까 아니면 전면에서 왔습니까?Asayer는 이러한 질문에 답하고 코드에서 수정 또는 최적화가 필요한 부분을 찾아내는 데 도움을 줍니다.일관성이 없는 성능은 고객 손실을 초래하고 보존율과 수익을 떨어뜨리기 때문입니다.
우리가 민첩성을 포옹할 때, 우리는 그 어느 때보다 코드를 더 자주 전송한다. 비록 우리가 가장 좋은 테스트를 했지만, 우리의 코드는 결국 여러 가지 원인으로 인해 붕괴될 수 있다.그 밖에 앞부분은 다르다.이것은 서로 다른 브라우저에서 실행되고 복잡한 JS 프레임워크에 의존하며 여러 개의 CDN 층과 관련된다. 제3자 API, 잘못된 인터넷 연결, 기능이 그다지 강하지 않은 장치와 느린 백엔드의 영향을 받는다.사실 앞부분은 더 좋은 가시성을 필요로 하는데 Asayer가 바로 이 점을 제공했다.
너의 앞부분은 바로 너의 사업이다.이것은 사람들이 만지고 느끼는 것이다.우리가 그것을 신속하고 믿음직하며 즐겁게 하자.
Start monitoring your web app for free .