웹사이트, 블로그 페이지 속도 높이기 : 이미지 용량 줄이기

 

요즘 내 블로그 하루 방문자 수가 평균 200명 정도 된다.

정말이지 놀라운 발전이다. 방문자들의 유입이 점점 늘고 있는만큼 더욱 더 안정적인 블로그를 운영하고 싶다는 생각이 든다. 내 블로그가 사람들에게 빨리, 잘 보이는지 궁금해져서 내 블로그 페이지의 속도를 확인해보기로 했다. 

 

구글 페이지스피드 인사이트 

https://developers.google.com/speed/pagespeed/insights/

PageSpeed Insights

 

위 사이트에 들어가서 확인했는데... 충격. 

 

내 블로그는 모바일 유입이 더 많기에 이 빨간색의 신호는 좋지 않다...

 

이렇게 되면 사람들이 내 블로그에 들어와도 블로그 페이지가 바로 안 나타나고 로딩이 걸리기 때문에 잠깐 들어왔다가 나가버릴 수도 있다. 앙대... 

 

데스크톱은 다행히 속도가 무난했다. 휴.

 

모바일 속도 페이지의 스크롤을 내리니 추천과 진단이 뜬다.

 

블로그를 살리기 위해 구글에서 추천하는 대로 해보기로 한다.

 

차세대 형식을 사용해 이미지를 제공하기

'JPEG 2000, JPEG XR, WebP와 같은 이미지 형식을 사용하면 PNG 또는 JPEG보다 압축률이 높으므로 다운로드 속도가 빠르고 데이터 소비량도 줄어듭니다.'

 

JPEG 2000, JPEG XR, WebP요...? 오... 처음 들어보는 이름들인데... (컴알못)

 

항목을 열어보니 위의 설명이 덧붙여져 있었고 크기가 큰 사진들이 30개 정도 쭈루룩 나열되어 있었다. 이 추천대로 사진들을 JPEG 2000, JPEG XR 로 변환시켜주는 프로그램을 찾아 용량이 큰 사진을 하나 변환시켰다. 그리고 블로그에 올리는데... 오!! 올라가지가 않는데요?ㅎ 끙. 사진 용량을 줄이긴 해야 하는데... 그렇다고 사진 크기를 작게 만들기는 싫어서 고민하다가 검색하니 이런 사이트가 나왔다. 

 

https://tinypng.com/

TinyPNG – Compress PNG images while preserving transparency

 

Tinypng :) 사진의 품질은 유지해주고 용량은 줄여주는 사이트다! 

 

이용방법은 이러하다. Drop~ 부분에 이미지를 드래그해서 놓고 다운로드하면 끝! 참 쉽죠?

 

거의 용량이 3분의 1로 줄어들었다. 대박! 화질은 괜찮을까?

 

왼쪽이 원본, 오른쪽이 용량이 작아진 사진이다. 색감의 차이가 보이나 보기에 크게 불편하지는 않다. 

 

사진 하나하나 드래그하지 않고 사진 여러개를 선택해 한 번에 드래그할 수도 있으니 편리하다

 

사진을 하나씩 다운받아도 되지만 귀찮으니까 download all을 눌러 모든 파일을 다운로드 해준다

 

블로그에 올려져 있었던 사진 30개를 용량을 줄인 사진으로 수정해주었다. 몇 개는 사진 크기가 그대로인데 어떤 사진들은 사진 크기가 좀 더 작아져있었다. 참고로 나는 용량을 줄인 사진이 대부분 게시글의 대표사진이었기 때문에 기존의 사진을 지우고 ★새로 올린 사진을 대표 사진으로 꼭 체크를 해줬다!★ 체크를 안 하면 블로그에 보이는 대표사진은 용량이 예전 걸로 그대로 남아있어서 예상절감치가 줄어들지 않더라.

 

그럼 수정 후에 페이지 속도가 더 빨라지게 되었는지 확인해보자.

 

띠용? 그대로다

 

차세대 형식 항목의 예상 절감치가 33.93s 에서 0.3s 로 대폭 줄어들긴 줄어들었다.

 

추천 옆에 있는 글을 자세히 읽어보니 권장사항은 페이지를 더 빠르게 로드하는데 도움이 될 수 있으나 성능 점수에는 직접적인 영향을 미치지 않는다는데... 그래서 점수가 그대로인걸까? 끙... 

 

직접적인 영향을 끼치지 않는다는 말이 뭔 말인가 싶어 클릭했는데 영어... 예... 

 

성능 점수는 퍼포먼스 메트릭스(performance metrics), 즉 성능 측정 지표로만 결정이 되어지고 추천/진단 부분은 직접적으로 성능 점수에 기여하지 않는다고 되어있다. 

 

측정 결과는 동등하게 가중치가 주어지는 것이 아니라 최근에는 이렇게 측정되고 있다고 한다. 

 

• 3X - first contentful paint (첫 번째 텍스트 또는 이미지가 그려지는 시간을 표시함)
• 1X - first meaningful paint (페이지의 기본 내용이 표시될 때 측정함)
• 2X - first cpu idle (페이지의 주 스레드가 입력을 처리할 수 있을 만큼의 조용한 상태에서 처음으로 표시됨) 
• 5X - time to interactive (페이지가 완전히 상호 작용하는 시간을 표시함)
• 4X - speed index (페이지 내용이 얼마나 빨리 표시되는지에 대한 속도를 나타냄) 
• 0X - estimated input latency (가장 바쁜 5초 동안의 페이지 로드 기간 동안 앱이 사용자 입력에 응답하는 데 걸리는 시간, 밀리초를 예측한 것. 지연 시간이 50ms 이상이면 사용자가 앱을 지연으로 인식가능) 

 

오... 찾아봐도 뭔말인지 모르겠는데?ㅎ 그래서 어떻게 해야 한다구...? (컴알못의 위기) 

이와 관련된 타블로그 게시물이 있어서 링크를 걸긴 걸지만... 사실 난 봐도 모르겠다^^

 

https://medium.com/@koh.yesl/preload-prefetch-and-priorities-in-chrome-15d77326f646

Preload, Prefetch And Priorities in Chrome

 

차세대 형식 예상절감치가 확 줄어들긴 했으니 다른 부분도 일단 수정해봐야겠다.

그건 다음 포스팅에서 다룰 예정! 다음에 만나요~