프론트엔드 개발자는 유저에게 좋은 경험을 제공해야 한다는 의무가 있습니다. 이번에는 프론트엔드 개발자가 유저에게 좋은 경험을 제공할 수 있는 skill중 하나인 preFetch에 대해 이야기 해보려합니다. 우리는 프로덕트를 개발하면서 유저의 다음 행동을 어느정도(?) 예상할 수 있습니다. 다음 예시를 한번 보시죠. 위 사진은 제가 진행한 '대박 사건'이라는 편지 서비스의 페이지 일부입니다. 해당 페이지는 박을 터트리면 박 속에 들어있던 편지지들이 나타나는 페이지입니다. 그렇다면 위 상황에서 유저의 다음 행동을 예상해볼까요? 1. 유저는 박을 클릭하여 터트려 박 속에 들어있던 편지지들을 볼 것이다2. 뒤로 돌아간다 아마도 위 두 가지 정도로 유저의 다음 행동을 예상할 수 있을 것입니다. 만약 네트워크 환경..

이번에는 리액트 프로젝트에서 내가 진행했던 번들 사이즈 최적화에 대해 이야기 해보려 합니다. 그렇다면 왜 나는 번들 사이즈를 최적화하려 했을까?우선, 우리 서비스를 프로덕션 레벨에서의 성능을 확인해보기 위해 build를 해보았습니다. 위 스크린샷을 보면 root 밑의 assets/index-UgkYlaLr.js 하나의 파일로 번들 파일 전체를 차지하고 있는 것을 볼 수 있고, 밑에 스크린샷의 로그에서는 index-UgkYlaLr.js의 크기가 704.19KB인걸로 매우 크다는 걸 알 수 있죠. 로그에 나와있는 경고에도 500KB가 넘는다고 알려주며 코드 스플리팅을 해서 사이즈를 줄이라고 권장하고 있습니다.코드 스플리팅이란 무엇인가?코드 스플리팅은 말그대로 한국어로 번역하면 코드 분할입니다. 우리가 코드 ..

이전에 진행했던 프로젝트에서 이미지 확장자로 .png를 사용했었다. 하지만 png는 jpeg, webp에 비하면 용량이 훨씬크다. 이렇게 되면 이미지를 렌더링 하는 데 있어서도 시간이 오래걸리고 이는 유저의 페이지 이탈을 야기 할 수 있다. 우선 png가 왜 타 확장자에 비해 용량이 큰지 알아보기 위해 올리브영 기술 블로그를 참고하여 레스터 이미지와 벡터 이미지에 대해 알아보자. ✅ 레스터 이미지 래스터 이미지는 픽셀에 표현하고자 하는 색상을 그려서 이미지 형태로 표현하는 방식이다. 개발자들이 주로 사용하는 JPEG, PNG, GIF 등이 대표적인 레스터 이미지이다. 이 레스터 이미지는 여러 픽셀이 모여서 하나의 이미지를 만들기 때문에, 사이즈가 크거나 품질이 더 좋은 이미지를 만들기 위해서는 그만큼의 ..

해당 성능 최적화 포스팅은 여러 주제로 나누어 시리즈로 작성 할 계획이다. 이전에 진행했던 프로젝트에서 시간이 급급한 나머지 놓쳤던 성능 최적화 부분에 대해 리팩토링을 해 보았다. 우선 유저에게 가장 먼저 보여지는 화면을 개발하는 프론트엔드 개발자는 유저에게 제공하려는 웹 사이트를 빠르게 보여줘야하고, 사용자의 동작에 따른 빠른 인터랙션을 제공해야한다. 즉, 좋은 사용자 경험(UX)을 제공 해야하는 것이다. 아래는 구굴이 공개한 시간대별 페이지 이탈률로 페이지 로딩 시간이 1초에서 3초로 증가하면 페이지 이탈률이 32%로 증가한다고 하고, 1초에서 10초가 되면 페이지 이탈률이 123%나 된다고한다. 프론트엔드 성능 최적화에는 성능 최적화 외에도 접근성, SEO 등 다양한 부분이 있지만 우선 성능 최적화..

JavaScript를 사용하는 개발자라면 개발을 하면서 디버깅을 하기 위해 console.log()를 많이 사용 할 것이다. 협업을 하는 과정에서 디버깅을 위해 작성했던 console.log()를 코드리뷰를 통해 발견하여 제거 할 수도 있지만, 이 또한 사람이 하는 일이라 못 보고 지나쳐 console 로직이 그대로 main에 push되어 배포 사이트에서 console이 찍히는 일이 조금씩은 있을 것이다. 지금부터 배포 단계에서 자동으로 console이 제거되어 개발자들이 마음 놓고 console을 찍어 디버깅 해볼 수 있도록 설정해보자! 하지만 이 설정은 동료 개발자들의 human error를 줄여주기 위한 수단 일 뿐, console이 main 브랜치에 남아있으면 보기 좋지 않으니 무조건 consol..

최근 진행했던 짤을 공유하고 자유롭게 사용할 수 있는 "짤뮤니티" 프로젝트에서 맡았던 OAuth 2.0 로그인 기능에 대해 작성해보려 한다. 우선 나는 잘 모르는 서비스에서 회원 가입을 요구할 때, 대부분 거부감이 들었었다. 내 개인 정보를 잘 모르는 서비스에 제공해야 한다는 것이 썩 내키지 않았기 때문. 그렇다면 다른 사용자들도 나처럼 거부감이 들지는 않을까? 또 회원가입을 해야 하는 프로세스 자체가 귀찮지는 않을까?라는 고민에서 시작되어 자체 회원가입 및 로그인 없이 Oauth 2.0 서비스를 사용하기로 결정하였고, 구글, 카카오, 네이버 총 3개의 서비스를 이용하여 로그인을 진행했다. 우선 OAuth의 프로세스를 알아보기 전, OAuth에서 쓰이는 구성 요소 용어에 대해 알아보자.OAuth 구성 요..

기존에 진행했던 SNS 플랫폼 기반 익명/기명 편지 서비스 "대박 사건" 프로젝트에서 각 페이지에 따로 구현되어 존재했던 편지 작성, 이전에 작성한 편지 수정, 댓글 작성 컴포넌트(모두 Textarea로 이루어짐)를 공통 컴포넌트로 묶어 재사용성을 높여보았다. 위 구조로 완성된 UI와 문제점에 대해 간단하게 알아보자. 위 사진의 주황색으로 표시된 컴포넌트 모두가 비슷한 UI를 가지고 있고 우측의 이전 편지 수정하는 컴포넌트만 버튼 아이콘 두 개가 추가되어있다. 위 UI를 바탕으로 현재 코드의 문제점은 코드의 중복. 이를 해결하기 위해 Textarea를 하나의 고정된 UI를 가지고 있는 공통 컴포넌트로 구현하려 고민했었고, 당시 생각했던 구조는 아래와 같다. 하지만 위와 같은 설계는 치명적인 단점이 존재했..