Lazy loading이 성능을 낮출 수도 있습니다.
2023. 9. 13.
첫번째 뉴스레터가 React에 치중되어 있는 것 같아서, 다양한 FE 전반의 정보를 느낄 수 있도록 여러가지 정보를 가져왔습니다. 이번주도 좋은 정보가 되었으면 하는 바람과 함께 다음주에 만나요 :)
Lazy loading이 성능을 낮출 수도 있습니다.
심윤섭: Shopify 고객이 쉽게 놓칠 수 있는 세가지 성능 이슈에 대해 소개한 글입니다. 첫 번째인 lazy loading이 가장 보편적으로 보여서 가져왔습니다. 이유도 렌더링 트리를 그려가며 설명해서 이해하기 쉽구요.(CSS 비동기 로딩/fetchpriority는 Code Spliting/Cross browsing때문에 보편적이 아니긴 합니다.) 요약하자면 lazy loading을 Large Content(Image)에도 적용될 경우에 Chrome의 Preload scanner에도 걸리지도 않을뿐더러 IntersectionObserver가 트리거 된 후에 image를 로딩하기 때문에 적용하지 마라라는 이야기입니다. IntersectionObserver가 native lazy loading에도 쓰이는 것이 신기한 점이네요.
최원빈: React.memo에 대한 글을 볼 때도 느낀 건데, 어떤 상황이던 쓰기만 하면 성능이 좋아지는 마법 같은 기능은 없다는 것을 또 느끼네요.(있다면 default 프로퍼티가 됐겠죠?) 대부분의 상황에서 이점을 얻을 순 있어도, 모르고 쓴다면 손해를 볼 수 있다는 점에 유의하도록 해요.
김대관: 화면을 통해 사용자들에게 더 좋은 서비스 경험을 줘야하는 프론트엔드 개발자들이 항상 고민해둬야할 이미지 로딩문제를 설명해주고 있네요. lazy loading을 통해 성능을 향상시켰다고 생각할 수 있지만, 실제로는 성능도 제대로 못 챙기고 UX마저 저하될 수도 있다는 사실을 배워갑니다.
제 IDE/CI가 느려요: 타입스크립트
심윤섭: DX가 나쁜 것은 서비스에도 영향을 미칩니다. HMR이 생긴 이후로 HMR이 안되면 불편해하면서 해당 기술을 포기할정도로요. 이 영상은 TypeScript의 타입 체크/빌드가 느린 보편적인 이유와 탐지 및 해결방법을 알려줍니다. "swc나 esbuild를 쓰면 빠르지 않나요?"라고 말하신다면 트랜스파일 속도만 빠르게 해줄 뿐 타입 체크를 해주지 않으므로 아직은 추적 후 느린 이유를 찾는 방법밖에 없으므로 이 영상에서 말하는 주의해야 할 점을 알고 계시면 좋을것 같습니다!
김대관: 해당 영상에서는 타입스크립트의 빌드가 느린 이유를 알려주면서 타입스크립트의 컴파일러가 동작하는 방식을 짚어주며 풀어주는 유익한 발표 영상입니다. 특별하게 빌드가 느리지 않다는 것을 체감하지 못했더라도, 해당 영상에서 타입스크립트 컴파일러가 어떻게 동작하는지, 기술적으로 어떻게 해결할 수 있는지를 쉽게 알아 갈 수 있습니다.
모노레포 적용기: 희망편
심윤섭: 모노레포로 전환 적용기와 적용을 하게되면 좋은 점을 쓴 글입니다. 희망편이라고 적어놓은 이유는 절망편이 따로 있어서는 아닙니다. 하지만 장점만 있는 것은 아니기 때문에 항상 팀과의 충분한 논의 끝에 모노레포를 도입하시길 바랍니다. git subtree를 사용해도 되고요! 자세한 것은 monorepo vs polyrepo를 참고하세요.
김대관: 확실히 레포지토리 하나씩 옮겨다니는 것은 일이라고 생각합니다. 하지만 “레포지토리 간의 기능이 일관되지 않다면, git 관리에 있어서 모노레포 생성은 지양해야하는 부분이 아닌가”? 라는 생각이 듭니다.
최원빈: 서비스를 확장하다 보면 반드시 다른 도메인의 로직을 가져오거나, 동일한 함수를 호출해야 할 일이 생깁니다. 같은 모델을 공유하는 일은 더욱 흔하죠. 모노레포는 이런 경우에 정말 유용합니다! 다만 모노레포 적용 시 공통 모듈 부분은 사이즈가 커질 수록 수정하기 힘들어지기에 레거시가 될 수 있는데, 이럴 때 여러 프로젝트를 동시에 수정해야하다보니 건들기 힘들어지는 경우가 많으니 더 불어나기 전에 주기적으로 해소하는 것이 중요합니다.
인터렉션 넣기에 24시간이 모자라
심윤섭: 토스의 디자인 컨퍼런스인 simplicity 23의 세션 중 하나인 인터렉션에 대한 세션입니다. 보통 디자이너가 신경써야 하는 부분인 인터렉션을 가져온 이유는 결국 FE 개발자가 이 부분을 구현해야 하기 때문에 “목적이 확실하다면 인터렉션에 애니메이션을 넣는 것이 좋다.”와 “기존 시스템에 반하는 시스템을 만든다면 쉽게 사용할 수 있는 것에 초점을 맞춰라”는 부분이 와닿아서 가져왔습니다. 디자이너가 애니메이션을 만들 때 조언을 해줄 수도 있구요 😊
세밀한 반응형 프로그래밍 알아보기
→ 한국어 번역
심윤섭: Reactivity라고 쓴 이유는 Reactive Programming을 말하려는게 아니라 프론트엔드 패키지 전반에 있는 Fine-Grained Reactive Programming을 살펴보기 위함입니다. 실무에 바로 적용할 수 있는 좋은 정보라고 생각되지는 않지만 복잡한 시스템을 만들 때 한 번 생각해볼 만한 패턴들입니다.
최원빈: 바닐라 개발을 할 때 유용한 패턴과 기술들이 잘 정리되어있습니다. Observable-ish는 생소하지만 인상적이네요. 사실 유용하다기보단 공부가 되는 패턴들에 가깝지만, 언젠간 한번쯤은 복잡한 구현체를 만들어야 할 날이 오지 않을까요? 미리 알아둔다면 그 날에 다양한 방향으로 아이디어를 낼 수 있을거예요!