오늘 배웠던 최적화 관련하여 Lighthouse를 이용하여 내가 이용하는 웹 페이지를 검사 해보았다.
오늘 검사해 본 웹 페이지는 https://www.surfit.io/ 바로 서핏이다.
서핏의 Lighthouse 검사 결과는 이렇게 나왔는데 Best Practices , SEO 에서는 좋은 점수가 나왔지고,PWA는 데스크탑용으로 검사를 해서 그런지 결과는 나오지 않았다. 그 중 Performance 에서 점수가 낮게 나와 한 번 확인 해보았다.
참고
Best Practices = 웹 페이지가 웹 표준 모범 사례를 잘 따르고 있는지 확인 한다. HTTPS 프로토콜을 사용하는지, 사용자가 확인할 확률은 높지 않지만 콘솔 창에 오류가 표시 되지는 않는지 등을 확인
SEO = 이 전에도 배웠듯이 검색 엔진 최적화가 잘 되어있는지 확인 한다.
Performance
Performance 항목은 웹 성능을 측정 하는데 화면에 컨텐츠가 표시되는 시간이나 사용자와 상호 작용을 할 수 있는 시간은 얼마나 걸리는 지를 측정 한다.
Performance 결과가 왜 이렇게 낮게 나오는 지 확인을 해봤는데 , Largest Contentful Paint , Time to interactive , Total Blocking Time 에서 안 좋은 결과가 나온 것으로 확인 되었다.
Largest Contentful Paint는 뷰포트를 차지하는 가장 큰 콘텐츠(이미지 또는 텍스트 블록)의 렌더 시간을 측정한다.
Time to interactive는 페이지가 로드 된 후 사용자가 상호 작용을 할 수 있는 데까지 걸리는 시간을 나타낸다.
Total Blocking Time은 페이지가 유저와 상호작용하기까지의 막혀있는 시간을 측정합니다.
이 세가지가 많이 느려서 Performance 점수가 낮은 것으로 확인 된다.
이에 대한 해결 방법을 알아 보기 위해 OPPORTUNITIES를 확인 해보았다.
여기서 나타난 몇 가지 문제점 중에서 가장 큰 3가지를 확인 했다.
첫 번째로는 네트워크 전송 할 때 보내는 text의 크기가 너무 커서 시간이 오래 걸려(gzip , deflate or brotli)를 사용하여 사이즈를 줄이라고 나와 있다.
첫 번째 줄에 나와 있는 /js/app-dist.js~~를 확인해 보았다.
여기서 Response Headers를 확인해 보면 컨텐츠의 크기를 압축시키지 않고, 그대로 보내주는 것을 확인 할 수 있다.
그림에서 처럼 보통 js파일에서 gzip같은 컴프레서를 사용하여 크기를 줄이면 헤더에 무엇으로 컴프레스 했는지 확인이 가능한데, 서핏에서는 컴프레스를 하지 않아 크기가 큰 것으로 확인되며, 결과 적으로 서핏에서는 크기를 줄이지 않아 여기서 시간을 가장 많이 사용하는 것으로 확인 된다.
이것에 대한 문제점은 밑에서도 바로 확인이 가능하다.
밑의 DIAGNOSTICS에서 첫 번째를 확인 해보면 막대한 양의 네트워크 페이로드를 피하라고 나와 있는데, 이게 바로 위에서 나타난 text의 크기가 너무 크다는 것이다.
이것에 대한 해결 방법으로는
1.페이로드가 필요할 때까지 요청을 연기합니다.
ex)PRPL 로딩 방식 적용
2.요청을 최대한 작게 최적화합니다.
네트워크 페이로드를 최소화하고 압축합니다.
이미지에 대해서는 JPEG 또는 PNG 대신 WebP를 사용합니다.
3.페이지가 반복 방문 시 리소스를 다시 다운로드하지 않도록 요청을 캐시합니다.
그리고 두 번째와 세 번째 문제점은
Reduce unused JS ,CSS인데 이 문제점은 말 그대로 사용하지 않는 JS코드와 CSS코드가 많아 쓸데 없이 코드를 읽어 내는 시간이 있어 오래 걸리는 것으로 판단 된다. 그래서 사용하지 않는 JS와 CSS 코드를 최대한 줄여 최적화를 시키는 것이 바람직하다고 판단 된다.
Accessibility
그 다음으로 점수가 좋지 않은 부분이 Accessibility 부분인데
Accessibility는 웹 페이지가 웹 접근성을 잘 갖추고 있는지 확인 합니다.
지금 사진 상으로 확인을 해보면 버튼과 링크의 이름에서 접근성이 좋지 않다고 나와 있는데 그 이유를 확인해 보면
Button과 Link의 이름이 정확한 설명이 없이 지어져 있기 때문에 만약 스크린 리더를 사용하는 사용자라면 정확히 어떤 버튼인지 어떤 링크인지 이해하기 힘들어 사용하기 어려울 것이다.
aria-label을 이용하여 어떤 것인지 정확히 명시를 해준다면 웹 접근성이 더 좋아져 점수가 더 오를 것이라고 생각 된다.
마치며
이번에 처음으로 Lighthouse를 이용하여 웹 페이지를 확인해 봤다.
이용할 때는 웹 페이지가 되게 잘 만들어져 있다고 생각 했는데, 의외로 점수가 낮게 나오고 보완할 부분이 많다는 걸 보고 놀랐고 이런 문제점들을 어떻게 보완할 지를 공부해야 할 것 같다.
대부분 영어로 설명이 나와 어떤 문제점들이 있는 지는 확인하기가 좀 어려웠다.
