프론트엔드 개발자 엄성준 블로그

이전에 WiniLogis 프로젝트의 성능 최적화를 진행하면서 코드 스플리팅을 적용한 경험이 있습니다. 기존에는 SPA 특성상 메인 페이지에 접속하면 모든 페이지의 리소스가 하나의 JS 파일로 번들링되어 로드되고 있었습니다.이로 인해 초기 로딩 시 불필요한 코드까지 함께 로드되는 문제가 있었습니다. 이를 개선하기 위해 React의 Lazy와 Suspense를 활용하여 도메인 단위로 파일을 분리하고, 필요한 시점에만 리소스를 불러오도록 구조를 변경했습니다. 그 결과 메인 페이지에서 로드되는 코드 양을 281,862줄 → 63,303줄로 줄이며 성능을 개선할 수 있었습니다. 또한 이외에도 이미지 리소스 최적화, i18n 기반 다국어 처리 개선 등을 함께 진행하며 전반적인 성능 점수와 접근성 점수도 개선할 수 ..

현재 제 포트폴리오 프로젝트는 Next.js와 Supabase를 기반으로 구축되어 있으며, Vercel을 통해 배포 및 관리되고 있습니다. 그동안 Lighthouse 점수 개선, SEO 최적화, 이미지 최적화 등 프론트엔드 개발자로서 할 수 있는 다양한 최적화 작업을 진행해 왔습니다. 그 결과 성능 97, 접근성 85, SEO 100이라는 준수한 지표를 얻을 수 있었습니다. 하지만 지표와는 별개로, 실제 페이지 진입 시 질문 데이터를 불러오는 과정에서 이해하기 힘들 정도의 로딩 지연이 발생했습니다. 이번 글에서는 코드 레벨을 넘어 인프라 설정(Region)을 통해 이 문제를 해결한 과정을 공유합니다.왜 성능 지표는 좋은데 체감 속도는 느렸는가?Lighthouse는 정적 리소스 로딩과 초기 렌더링 성능..

화면 좌측 하단이나 우측 하단에 자주 보이는 Scroll To Top 버튼을 몇 번 구현한 적이 있습니다. 하지만 매번 스크롤 이벤트를 어떻게 활용해야 성능적으로 최적화할 수 있을까? 고민했었던 것 같습니다. 이번에는 그런 고민을 명쾌하게 해결하고, 더 깔끔한 방식으로 구현했기에 경험을 공유하려 합니다. 현재 저는 오토위니 모바일의 일부 JSP 레거시 페이지를 React 프로젝트로 마이그레이션 하는 작업을 진행 중입니다. 여러 페이지 중 해외 운송 정보를 보여주는 "Shipping Schedule" 페이지에 Scroll To Top 버튼을 적용했는데, 이번에는 기존 방식보다 더 최적화된 방식으로 개발할 수 있었습니다. #  기존 구현 방식의 비효율성 기존에 Scroll To Top 버튼을 구현할 때마다 ..