이미지 리스트 FCP First Contentful Paint 성능 개선

서론

이미지 데이터를 서버에서 받아올때, 이미지 src 태그로 바로 사용할 수 있는 string 형태로 바로 받아올 수 있는 것이 아닌, 이미지 데이터 정보 + 이미지 파일 다운로드를 통해 이미지를 화면에 띄울 수 있다.

 

1. 이름, 날짜 등이 포함되어있는 이미지 데이터 api를 먼저 호출 

2. 이미지를 받아오기 위한 이미지 파일을 다운로드하는 api를 호출 

 

두 가지를 api를 활용해서 화면에 이미지를 띄운다.

 

문제

이미지 목록을 화면에 띄울때 string 형태의 이미지 관련 데이터만 띄우는 것이 아닌 이미지 파일을 다운로드 받아서 화면에 표출해야하니, 이미지 데이터 목록을 먼저 쿼리로 받아오고, 받아온 목록 정보로 이미지 파일을 다운로드 받고나서 화면에 렌더링하게 했다. 

그랬더니 전체 이미지가 다운받아져야지만 화면에 렌더링되니, get 해오는 동안에는 마치 화면에 아무것도 없는 것 같이 로딩 시간이 조금 길게 느껴졌다. 

 

개선 

- 주요 개선점 

아직 이미지를 다운받지 않아 이미지를 볼 수 없더라도 이미지 텍스트 데이터를 먼저 화면에 띄우고 이후에 이미지를 다운받게 하여, 사용자에게 먼저 보여줄 수 있는 컨텐츠를 보여주도록 변경했다. 크롬브라우저의 Performance insights 툴을 활용해서 First Contentful Paint 시간을 측정했고, 약 1.1초 가량 성능을 개선했다. 

 

- 추가 개선점 

이미지 아이템 컴포넌트에서 수정버튼을 누르면 이미지 모달이 열리는데, 이전엔 모달 컴포넌트가 개별 이미지 아이템 컴포넌트 내부에 포함 되어있었다. 이 경우 이미지 목록이 수십개가 된다면 DOM 노드 수도 x2배로 증가한다는 문제가 보였다.

따라서 컨테이너에서 수정 모달을 한 개만 포함시키고, 이미지 목록 중 현재 클릭하고 있는 데이터를 추적하여 모달을 열면 해당 데이터가 뜨도록 개선하였다. 

 

개선 이전 vs 이후 코드 

개선 이전 코드

1. 이미지 파일 다운로드 로직 

 

PhotosContainer

  const { data: photosData, isSuccess: isSuccessGetPhotos } =
    useGetPhotosQuery(siteId);

  const [photosList, setPhotosList] = useState<
    (void | undefined | Photo)[]
  >([]); //서버에서 받은 사진목록 데이터에 다운로드받은 파일을 추가한 내부 상태값

  useEffect(() => {
    if (isSuccessGetPhotos) {
      const imgFileIncludedPromiseList = photosData.map((el: Photo) => {
        if (el.id)
          return downloadSiteImageFile(el.siteId, el.id)
            .then((res) => {
              // console.log(res, '다운로드사진파일 res'); //Blob{size: 38229, type: 'image/png'}
              if (res) {
                return {
                  ...el,
                  imgFile: res,
                  imgUrl: URL.createObjectURL(res),
                };
              }
            })
            .catch((err) => console.log(err));
      });

      Promise.all(imgFileIncludedPromiseList) //이미지 파일 포함된 프라미스 형태의 리스트 
        .then((values) => setPhotosList(values))
        .catch((err) => console.log(err));
    }
  }, [isSuccessGetPhotos]);

 

서버에서 받아오는 기본 이미지 데이터 목록인 `photosData`를 loop으로 돌리면서 해당 id를 가지고 사진 파일을 다운로드 받는다. 그리고 다운로드 받은 결과값을 프라미스로 저장해서 화면에 띄울 `photosList`라는 상태값에 저장한다.

 

PhotoCard

<Card sx={{ maxWidth: 160 }}>
        <CardMedia
          sx={{
            width: 160,
            height: 160,
          }}
          image={photoData.imgUrl}>
          <Box display={'flex'}justifyContent={'space-between'}>
            <IconButton onClick={() => handleChangeOpenPhotoModal(true)}>
              <ModeEditIcon />
            </IconButton>
            <IconButton onClick={handleThumbnailImg}>
              <CheckCircleIcon
                color={photoData.isThumbnail ? 'primary' : 'inherit'}
              />
            </IconButton>
            <IconButton onClick={handleDeletePhotoData}>
              <CancelIcon />
            </IconButton>
          </Box>
        </CardMedia>
        <CardContent>
          <Box>
            <Typography
              noWrap
              color='text.secondary'
              sx={{ wordBreak: 'break-word' }}>{photoData.description}</Typography>
            <Stack direction='row' spacing={1}>
              <Typography>구역정보: </Typography>
              <Typography
                color='text.secondary'
                sx={{ wordBreak: 'break-word' }}>{photoData.area.siteAreaName ?? '전체'}</Typography>
            </Stack>
          </Box>
        </CardContent>
      </Card>

 

상위컨테이너에서 쿼리에서 받아온 `photoData` 데이터를 props로 그대로 전달 받아서 화면에 그대로 렌더링하는 view 역할을 한다. 

 

 

2. 수정 모달 

 

PhotoCard

      <PhotoModal
        photoData={photoData}
        areasList={areasList}
        handleUpdatePhoto={handleUpdatePhotoData}
        isPhotoModalOpen={isPhotoModalOpen}
        onChangeOpenPhotoModal={handleChangeOpenPhotoModal}
      />

 

PhotoCard 컴포넌트 내부에서 PhotoModal 컴포넌트를 렌더링한다. 

화면에서는 수정 버튼을 누르면 해당하는 모달이 한 개만 뜨는 것이라 모달 제어하는 로직 및 모달 컴포넌트는 한개만 필요한데, 이대로라면 PhotoCard 컴포넌트 개수만큼모달 컴포넌트의 개수가생기는 문제가 있다. 즉 쓸데 없는DOM 노드가 생성된다.

 

개선 이후 코드 

1. 이미지 파일 다운로드 로직 

 

PhotosContainer

        <Box display='flex' flexWrap='wrap' gap={2}>
          {isSuccessGetPhotos &&
            photosData?.map((el) => (
              <PhotoCard
                key={el.id}
                photoData={el}
                onChangeOpenPhotoModal={handleOpenEditPhotoModal}
                onSetCurrentPhotoData={(data) =>
                  setCurrentPhotoData(data)
                }></PhotoCard>
            ))}
        </Box>

 

이미지 파일을 다운로드 받기 전에 쿼리에서 받아온 기본데이터 `photosData`를 PhotoCard 컴포넌트에 props로 넘겨준다. 그러므로 이미지가 화면에 보이지 않아도 관련 텍스트 데이터는 먼저 화면에 뜰 수 있게 된다. 

 

 

PhotoCard

  useEffect(() => {
    //사진파일 다운로드
    if (photoData.id) {
      downloadImageFile(photoData.siteId, photoData.id)
        .then((res) => {
          setDownloadedImgUrl(URL.createObjectURL(res));
          setDownloadedImgFile(res);
        })
        .catch((err) => console.log(err));
    }
    return () => {
      URL.revokeObjectURL(downloadedImgUrl);
    };
  }, [photoData.imgFileId]);

 

그리고나서 하위 카드 컴포넌트 내부에서 사진 파일을 개별로 다운로드하도록 했다. 

 

 

2. 수정 모달

 

PhotoCard 내부의 수정 버튼을 열면 해당 포토카드 컴포넌트에 해당되는 데이터로 채워진 모달이 열려야함으로컨테이너에서 모달 컴포넌트를 한 개만 가지고 있도록 변경하고, 클릭한 현재 데이터를 부모에서 상태값으로 추적한다. 

 

PhotosContainer

  const initialSitePhoto = {
    siteId: siteId,
    imgFile: null,
    imgUrl: '',
    description: '',
    area: {},
    isThumbnail: false,
  };
  
 const [currentPhotoData, setCurrentPhotoData] = useState(initialPhoto);
 const [isEditPhotoModalOpen, setIsEditPhotoModalOpen] = useState(false); //사진 수정 모달 상태

 {/* 수정 모달 */}
      {isSuccessGetAreasFlatData && (
        <PhotoModal
          areasList={areasFlatData}
          isPhotoModalOpen={isEditPhotoModalOpen}
          onChangeOpenPhotoModal={handleOpenEditPhotoModal}
          type='edit'
          photoData={currentPhotoData}
          onUpdatePhoto={handleUpdatePhotoData}
          isThumbnailImg={currentPhotoData.isThumbnail}
          onUpdateThumbnailImg={handleUpdateThumbnailImg}
        />
      )}

 

클릭한 카드에 따라 해당 데이터를 PhotoModal 컴포넌트로 넘겨주어야 함으로 클릭한 데이터를 `currentPhotoData` 라는 상태값으로 관리한다.

 

구조

 

┣ PhotosContainer

    ┣ PhotoCard

    ┣PhotoModal

 

이슈 해결

 

여기서 이슈를 하나 만났다.

수정 모달이 동작하길 원하는 로직의 순서는 아래와 같았다.

 

1. 하위 포토카드 컴포넌트에서 수정 버튼을 클릭하면 상위 부모 컨테이너로 데이터를 넘겨준다.

2. 부모 컴포넌트는 하위에서 전달받아온 데이터로 `currentPhotoData` 상태를 변경한다.

3. 컨테이너에서 변경된 해당 상태값을 하위 모달 컴포넌트에 넘겨준다. 

 

그런데 모달을 열면 최신의`currentPhotoData` 상태가 아닌 이전에 눌렀던 데이터가 남아있는 문제가 있었다. 즉 컨테이너에서 상태값이 변경되기 이전에 모달이 열리고, 변경되기 이전 값이 모달을 열때 나타나는 싱크 문제 였다.

결국 모달컴포넌트에서 useEffect를 활용해서 props로 받아오는 `currentPhotoData` 가 변경되면 다시 모달을 렌더링 할 수 있도록 해결했다.

 

개선 이전 vs 이후 성능 비교

CPU No throttling 

FCP(First Contentful Paint)

리팩토링 전 vs 후 

FCP인 최초 컨텐츠 렌더링 시간은 개선 전 후 각각 0.26초, 0.25초로 거의 비슷했다. 그런데 이 FCP 시간에 뜨는 화면 캡쳐를 보면 차이가 확연히 난다.

 

- 개선 이전

• FCP 시간에 이미지 데이터가 있음을 알 수 조차 없다. 이미지 컨테이너를 감싸고 있는 div 박스의 보더만 보일 뿐이다.

- 개선 이후

• 0.25초만에 이미지 데이터의 뼈대가 화면에 렌더링 된다. 아직 이미지는 보이지 않지만 사용자는 이미지 텍스트 데이터를 바로 접할 수 있고 실제 사진 이미지가 있을 거라는 것을 0.25초만에 인지 할 수 있다. 

 

LCP(Largest Contentful Paint)

 

이제 가장 큰 이미지의 렌더링 시간을 측정하는 LCP 시간(콘텐츠가 포함된 최대 페인트 시간)을 측정했다. 

 

- 개선 이전

• LCP 시간으로 측정된 1.35초 바로 직전에 이미지의 뼈대가 나타났다. 
• 즉 1.35초에 가까워져야 이미지 아이템의 뼈대가 나타나는 것으로, 이 말은 사용자가 이미지가 있다는 것을 인지하려면 거의 1.35초에 가까운 시간이 걸린다는 것이다. 그 동안은 로딩 skeleton ui를 따로 띄우지 않는 이상 사용자는 이미지 정보가 존재하지 않는 것인지 데이터가 로딩 중인 것인지 모른다. 

- 개선 이후

• LCP 시간은 1.16초로 이 시간에 가장 큰 이미지가 한 개가 렌더링되기 시작하고 이후에 차례차례 다운받은 이미지 파일이 렌더링된다. 

따라서 FCP 자체 측정된 시간은 0.25초 정도로 개선 전이나 후나 시간차가 없게 느껴져도, 이미지 데이터의 뼈대가 화면에 최초로 뜨는 시간을 고려해본다면 개선 전 후가 1초가 넘는 시간 차이가 나는 것을 볼 수 있다. 

 

LCP 모든 사진 다운로드 

1.35초 vs 1.42초

 

따로 성능 측정 항목에 표시되진 않지만, 궁금해서 모든 사진을 다운로드 받을때 까지의 시간을 측정해보았다. 

 

- 개선 이전

• LCP 시간인 1.35초에 다운로드 받아진 사진이 모두 나타났다. 

- 개선 이후

• 최초 한 장의 사진이 다운받아졌던 LCP 시간인 1.16초에서 조금 이후인 1.42초가 되어야 다운로드 받아진 사진이 모두 나타났다.

FCP 성능은 개선했지만 모든 사진이 다운로드 될때까지의 시간은 사실 더 느려졌다. 이전에는 컨테이너에서 모든 사진을 다운로드 받고 난 이후에 데이터를 모아 렌더링 했다면, 개선 이후에는 PhotoCard라는 개별 이미지 아이템 컴포넌트를 map 으로 돌면서 아이템 컴포넌트에서 사진을 다운로드 받는 로직이 있다보니 모든 사진이 다운로드 될때 까지는 조금 더 오랜 시간이 걸린 것 같다. 

 

이로써 첫 렌더링시 이미지 뼈대를 빨리 띄울 것인가? vs 첫 렌더링 시간은 좀 걸리더라도 사진이 모두 다 다운로드 된 화면을 빨리 띄울 것인가? 를 두고 고민을 하게 되었는데, 우선 첫 렌더링시 로딩시간이 느렸던 것이 주된 문제점이었으므로 FCP 개선에 초점을 맞추었다. 

 

CPU 6배 감속

성능 측정시 CPU No Throttling으로 하면 큰 차이가 느껴지지 않아, CPU 6배 감속이라는 옵션을 선택해서 같은 환경에서 동일한 메트릭을 측정해 보았다. 

FCP

 

FCP 1.21초 vs 1.08초 

역시 정상 트래픽 예제와 마찬가지로 FCP에서 개선 이전은 아무런 화면이 안보이고 개선 이후는 이미지 텍스트 데이터 뼈대가 바로 나타났다.

 

LCP

 

LCP 2.68초 vs 2.71초

정상 트래픽 예제와는 다르게 성능 개선 이후의 LCP가 조금 더 더디게 나왔다.

개선 이전은 LCP에 근접한 바로 이전에 이미지 뼈대가 나타났고, 개선 이후에는 LCP 시간에 근접해 있는 시간 이후에 이미지 사진이 한 개 다운로드 받아졌다.

 

LCP 모든 사진 다운로드 

2.68초 vs 3.06초

모든 사진을 다운로드 받는 시간은 개선 이전에는 LCP 시간에 정확히 모든 사진이 다운 받아졌고, 개선 이후에는 LCP 가 조금 한참 지난 3.06초가 다 되어서야 모든 사진이 다운로드 받아졌음을 측정할 수 있었다. 

 

이번 실험을 통해 최초의 렌더링 시간을 빠르게 할 것인지, 모든 이미지를 다운로드 받아 보여주기까지의 시간을 빠르게 할 것인지를 두고  trade-off 가 있었음을 느낄 수 있다. FCP LCP 두 메트릭이 다 GOOD에 해당되는 지표를 가지고 있다면 FCP나 LCP 중 어떤게 더 중요한지에 대한 정답은 없는 것 같다. 서비스/유저가 필요한 기능에 따라 어떤 것이 더 중요한 가치를 가지는지를 두고 성능 개선 전략을 짜는 것이 필요한 것 같다. 

이번에 FCP를 중점으로 개선을 했는데, 모든 사진을 다운로드 받는 시간은 개선하기 이전보다 조금 더 느려져서 이 부분을 또 더 어떻게 개선할 수 있을지 고민해보고 적용해보고 싶다. 

 

 

References

https://developer.chrome.com/docs/devtools/performance-insights?hl=ko

실적 통계: 웹사이트 실적에 대한 활용 가능한 분석 정보 얻기  |  DevTools  |  Chrome for Developers

https://web.dev/articles/fcp

First Contentful Paint (FCP)  |  Articles  |  web.dev