이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
FCP는 처음 뭔가 보이기까지, LCP는 가장 큰 핵심 콘텐츠가 뜨기까지라, 사용자에겐 언제부터 화면이 의미 있게 보이느냐입니다. 학부 프로젝트에서 첫 화면이 느렸을 때, 저는 무엇이 LCP를 늦추는지부터 봤습니다. 범인은 위쪽에 깔린 큰 이미지 하나였고, 그게 다 받아질 때까지 큰 콘텐츠가 안 떴습니다. 그래서 그 이미지를 더 작은 포맷으로 바꾸고, 처음 화면에 안 보이는 이미지는 나중에 받게 미뤘습니다. 체감상 큰 콘텐츠가 눈에 띄게 빨리 떴습니다. 다만 나중에 받게 미룬 이미지는 스크롤 시 잠깐 비는 대가가 생겨, 그건 자리만 미리 잡아 두는 식으로 보완했습니다. 그 경험 뒤로 저는 성능을 볼 때 지표 숫자보다 무엇이 그 지표를 잡고 있는지부터 찾습니다.
저는 성능 개선을 추측으로 손대지 않는다는 데서 시작합니다. 과제에서 첫 화면이 느리다는 말이 나왔을 때, 처음엔 코드가 무거워서라고 짐작했습니다. 그런데 측정해 보니 LCP를 잡은 건 코드가 아니라 웹폰트가 다 받아질 때까지 큰 글자가 안 그려지던 것이었습니다. 짐작과 원인이 달랐습니다. 그래서 글자를 기본 폰트로 먼저 보여 주고 웹폰트는 뒤에 교체하는 방식으로 바꾸자 큰 콘텐츠가 바로 떴습니다. 다만 교체 순간 글자 모양이 살짝 바뀌는 깜빡임이 대가로 생겨, 그게 거슬리지 않을 범위인지 확인하고 받아들였습니다. 그 경험에서 성능은 짐작이 아니라 측정에서 시작해야 한다는 걸 배웠고, 지금도 느리면 원인을 먼저 재고 손을 댑니다.
개선 기법은 많지만, 저는 효과가 큰 한두 개부터 본다는 편입니다. 과제에서 첫 화면이 느렸을 때 할 수 있는 게 여럿이었습니다. 코드 줄이기, 이미지 줄이기, 스크립트 미루기 등이었는데, 전부 하면 시간만 쓰고 무엇이 효과였는지도 모르게 됩니다. 그래서 측정으로 LCP의 절반 이상을 한 이미지가 잡고 있다는 걸 확인하고, 거기부터 손댔습니다. 그 하나만 줄여도 체감이 크게 바뀌어, 나머지는 우선순위를 낮췄습니다. 다만 이미지를 너무 줄이면 화질이 떨어지는 대가가 있어, 눈에 거슬리지 않는 선을 직접 비교해 정했습니다. 그 경험에서 개선은 다 하는 게 아니라 가장 큰 병목부터라는 걸 배웠고, 지금도 성능 작업은 효과 순으로 줄 세워 시작합니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 네이버 프론트엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.