production 환경과 development 환경

• 지금까지 이미지 사이즈 최적화, 병목 코드 최적화, 코드 분할 기법을 통해 서비스 성능을 향상해 보았음. 이 기법이 모두 적용된 상태로 목록 페이지 성능을 Lighthouse로 측정해 보면, 아래와 같이 처음 측정했던 점수보다 크게 향상된 것을 볼 수있음

• 그런데 여기서 간과하면 안 되는 것이 하나 있음. 블로그 서비스가 실행되고 있는 환경이 production 환경이 아니라 development 환경이라는 것임.
• 이 점을 짚고 넘어가야 하는 이유는 CRA의 경우 production 환경과 development 환경에 차이가 있기 때문임. 예를 들어, production 환경일 때는 webpack에서 경량화라든지 난독화 같은 추가적인 최적화 작업을 함. 반면에 development 환경에서는 그런 최적화 작업 없이 서비스를 실행함
• 즉, 각 환경에서 성능을 측정할 때 차이가 있으므로 최종 서비스의 성능을 측정할 때는 실제 사용자에게 제공되는 production환경으로 빌드된 서비스의 성능을 측정해야 함
• production 환경에서는 앞서 실행한 npm run start 명령어가 아닌 npm run build를 통해 서비스 코드를 번들링하고 최종적으로 빌드된 파일을 서비스하면 됨
• 빌드된 파일을 서비스 하는 방법에는 여러 가지가 있는데, 여기서는 미리 만들어둔 npm run serve라는 명령어를 통해 빌드된 파일을 서비스해보겠음

<aside> 💡 npm run serve 살펴보기

npm run serve 명령어에서는 먼저 빌드를 함. 빌드가 완료되면 serve라는 라이브러리를 통해 /build 폴더에 있는 파일을 서비스함. serve 라이브러리는 특정 파일 또는 폴더를 간단하게 웹에서 서비스할 수 있게 돕는 라이브러리임

</aside>

npm run serve 실행 화면

• serve 명령어가 정상적으로 실행됐다면 위와 같은 결과를 볼 수 있음
• 5000번 포트에서 서비스되는 것을 확인할 수 있음.
• npm run start로 실행한 것과 npm run serve로 실행한 것에 어떤 차이가 있는지 살펴보면 단순히 빌드 전후 서비스를 비교한 것이기 때문에 기능상 차이는 없음. 하지만 일부 번들 파일의 사이즈에 큰 차이가 있는 것을 볼 수 있음. chunk 파일의 이름이 조금 달라지긴 했지만, 가장 큰 chunk 파일을 보면 436kB에서 156kB로 줄어들었음. 왜냐하면 빌드할 때 경량화 같은 최적화가 이루어졌기 때문임

• 목록 페이지가 아닌 상세 페이지를 Lighthouse로 검사해보자

• production 환경(npm run serve)의 상세 페이지를 Lighthouse로 검사했더니 점수가 많이 낮음. 왜냐하면 상세 페이지의 경우 앞 절에서 분할했던 큰 패키지가 번들 파일에 포함되어 있고 블로그 글 내용이 모두 들어 있기도 해서 성능 점수가 목록 페이지에 비해 낮을 수 있음. 하지만 그럼에도 한 가지 짚고 넘어갈 부분이 있음. 바로 Opportunities 섹션에 있는 ‘Enable text compression’ 이라는 항목임