내가 만든 웹사이트, 잘 만든걸까? 객관적으로 어떨까? lighthouse + thinkwithgoogle

Lighthouse는 웹 페이지의 품질을 개선하기 위한 자동화된 오픈 소스 도구입니다. 공개 또는 인증이 필요한 모든 웹 페이지에 대해 실행할 수 있습니다. 성능(보통 렌더링 속도), 접근성(장애인 접근성), 프로그레시브 웹앱(PWA), SEO(검색엔진최적화) 등에 대한 감사가 있습니다.

Lighthouse는 Chrome DevTools, 명령줄 또는 노드 모듈로 실행할 수 있습니다. Lighthouse에 감사할 URL을 지정하면 Lighthouse에서 페이지에 대해 일련의 감사를 실행한 다음 페이지가 얼마나 잘 수행되었는지에 대한 보고서를 생성합니다. 거기에서 실패한 감사를 페이지 개선 방법에 대한 지표로 사용하십시오. 각 감사에는 감사가 중요한 이유와 수정 방법을 설명하는 참조 문서가 있습니다.

구글 크롬 개발자 도구에서도 Element / Source / 등등이 있는 탭에서 lighthouse 탭을 발견할 수 있고, 크롬 익스텐션으로 설치할 수도 있습니다. 내가 개발한 사이트의 URL을 Lighthouse에 검사대상으로 입력하면 위에서 언급한 항목들에 대해 100점 만점의 점수로 결과를 도출해줍니다.

이번에 만든 플라스크 웹서비스는 이런 점수를 받았습니다.

점수 올리기 전엔 이랬습니다.

다양한 항목을 조사하고 어느 정도는 납득할 만한 이유로 성능에 대한 지표를 다루고 있다는 생각이 드네요. ajax를 보내고 답을 받았을 때 데이터를 셋팅하는 지금 우리 사이트의 방식이 아무래도 성능 지표를 떨어뜨리고 있는 듯합니다. 정적으로 미리 가상의 데이터를 준비한 다음 내용을 지우고 새로운 값을 불러오는 것을 고민해봐야 할 것 같습니다. 

사실상 사이트가 로딩된 후에 거의 대부분의 데이터가 셋팅되는 방식이니 당연히 느릴 수 밖에 없겠네요.

정적 컨텐츠를 어느정도는 준지를 해놓아야 하겠다는 생각이 듭니다. 이미지 요소는 부모요소에 딱 맞춰 들어갈 것을 예상해서 사이즈 조절없이 입력하는 것보다 미리 로드될때부터 사이즈를 정해놓는 것이 좋다고 합니다. css에서 컨트롤하는 것보다 attribute로 width, height 값을 입력해주는게 좋은 것 같습니다. 체감상으로는 1초도 안걸리는 시간이라 문제를 느끼지 못했는데, 이런 검사는 throtting으로 3G,4G 인터넷 환경에서의 사용자 경험까지 중시하기 때문에 깐깐할 수 밖에 없습니다. 우리 사이트를 이용하는 모두가 쾌적하고 고사양인 컴퓨터만 사용하는 것이 아니니까요. 외부 css,js 등을 임포트하는 것도 꽤나 시간을 소요하는 것으로 판단하고, CSS-minifying 서비스를 활용했습니다.

저는 CSS 파일을 필요한 속성만 남겨주는 사이트인 https://purifycss.online/ 을 활용했습니다. html 파일의 코드와 css 코드 파일 전부의 내용을 입력하면 html에서 사용된 선택자들만 남겨주는 방식인데, 단 하나 주의할 점은 사용자 접속 후 로드되는 부분들까지 케어해야 하기 때문에 실제 html 코드보다 그런 정보들이 화면에 렌더링됐을때의 코드를 복사해야합니다.

png, jpg 등의 파일을 webp로 바꿨더니 그래도 칭찬받았네요.

부트스트랩에 비해 가볍다고 하는 Bulma 조차 저희가 직접 사용하고 있는 부분은 22.5% 정도 뿐이군요... 이렇게 결과물로 나온 코드는 띄어쓰기 없는 한줄짜리 코드라 포맷만 맞춰주면 완벽히 호환됩니다.

자바스크립트도 좀 수정을 해볼까요...??? 자바스크립트도 비슷한 역할을 해주는 사이트가 있습니다!!

JS 파일은 단일로만 사용했기 떄문에 스페이스만 없어진 느낌이네요.

이렇게 개발자도구에서 보면 모든 자바스크립트 코드가 그대로 나옵니다. 보기에 좋은 만큼 보안에도 약하겠죠? 크기는 17KB입니다.

변환한 코드를 텍스트로 복사한 것입니다 일단 줄바꿈이 없고 텍스트만으로는 11kb이네요.

참고로 자바스크립트는 문법을 조금만 달리하면 줄바꿈 없이 끝까지 작성가능한 개발 언어입니다:D 줄바꿈을 해주면 세미콜론 같은 것들을 적절한 위치에 삽입한 걸로 치고 읽을 뿐이죠

암튼 7kb라도 뭐라도 줄인게 좋으니까 덥석 물어서 사용하면 될까요...? 줄여놓은 코드를 한번 정렬한 다음에 두가지 코드를 차근차근 비교해보겠습니다.

기존의 코드입니다. 잘 쓴 코드는 아니겠지만 팀원들끼리 소통하기에 딱 적당한 수준이었습니다.

minify 된 코드입니다. 엄청나게 짧아졌고, 삼항 연산자등을 활용해 if 문을 거의 삭제했습니다. 일단 모든 변수 이름이 알파벳 한글자예요

이것이 잘못됐다거나 에러를 일으키는 코드가 될 것이라는 것이 아니라(오히려 동작은 몇 ms라도 빠르겠죠), 작업하는 사람이 코드의 맥락을 읽을 수가 없습니다. 이런 식의 리팩토링을 개발자가 일부러 하는 경우는 거의 없습니다. 대신 이런 역할을 해주는 도구는 충분히 많습니다. 왜 그럴까요? 누군가는 능력치가 너무 높으셔서 딱 보면 다 아는 것일까요? 아닙니다. 실제로 개발할 때는 위의 코드처럼 알아볼 수 있게 작성을 하고, webpack 등 js 파일 등을 컴파일할때 속도를 위해 컴퓨터에는 이렇게 줄인 코드를 넘기는 기능을 하는 빌드 도구들이 있습니다. 저희는 flask에서 직접 작성한 코드를 사용하고 있으니 자바스크립트를 저렇게 줄여쓰는 것은 좋지 못한 것 같습니다. 분명히 두 코드 모두 똑같이 작동하겠지만 바뀐 코드가 오히려 밑줄이 많이 그이고, 에디터도 알아는 듣지만 영 마음에 들어하지 않습니다... (아니 이해한다며?)이상하긴 하지만 그렇습니다.

한 웹사이트의 Source 탭의 코드입니다. 개발자가 실제로 이렇게 작성했을까요???

맨 위의 이미지와 캡쳐 시점이 다를 뿐(수정 후에 찍은 것)입니다. 꽤 높네요.

img 태그에 alt="이미지에 대한 정보"를 넘겨주거나, input이나 button 태그 옆에 label 태그를 달아주거나 다양한 태그에 title 태그 등을 달아주면 점수가 금방 오르는, 색약, 색맹, 시각 장애인 등의 접근성을 고려한 부분입니다. 까다롭지 않고 저처럼 금방 높이실 수 있습니다. 대비 항목은 생각지도 못했던 부분이네요. 색상도 조절해야 색 인식에 약하신 분들이 요소를 구분하기 쉬워질 거라 그런가봅니다. 보통은 스크린리더가 읽기 편한 html 파일인지 확인하는 점수라고 보시면 됩니다.

좀 까다로운 친구네요....

날씨 api + 주소 api 에 요청을 https로 보내지 않은 것(심지어 그 쪽에서 그리 달라한건데...), 주변 맛집 검색을 위해 geolocation을 사용한 것 등을 트집을 잡는데 api는 그쪽에서 https를 받지 않는다 했고 지리적 위치 권한 안전하게 받자고 https 서버에 그 고생을 했는데.... 당황스럽네요. 저해상도 이미지는 성능 빨라진다며 바꾸래서 바꾼건데 좀 어이가 없군요. 개발 이후 배포된 웹페이지에 콘솔 창은 되도록 깔끔한게 좋습니다. 오류든 값이든 개발할 때만 확인할 수 있게 배포 전에 지워주세요...

그래도 통과한 부분들을 보니 나쁘지 않습니다.

 

이번엔 칭찬만 받았네요 야호

SEO는 검색엔진최적화인데, 구글이나 네이버 등의 검색엔진이 24시간 많은 사이트를 파도타기순회하면서 각 페이지의 핵심적인 내용을 수집하고, 그 결과를 한국어 사이트의 경우 한국어 사용자에게, 또 어떤 사이트는 방문자 수 등으로 정보의 정확성을 파악해 구글 검색에 첫번째 칸에 오를 수 있도록 해야하니 그런 기준에 잘 들어맞을 수록 높게 나옵니다. 이 정도면 만족스러운 수준이네요. 실제로 SEO가 너무 낮으면 구글이 광고승인도 잘 안해줍니다.

여기까지가 LightHouse로 내 사이트의 지표 보기였습니다. 라이트하우스 사이트 검색 혹은 크롬 익스텐션 등으로 받아보실 수 있고, 또 속도면에 좀 더 집중한 결과서를 보고 싶으시다면 다음 테스트 사이트도 활용해보세요. "사용자는 3초 이상을 기다리게 하는 사이트에는 다시 접속하지 않는다"라는 강력한 기준에 의거한 팩트폭력을 맞을 수 있습니다.

Compare your mobile site speed