개인 블로그 관리하면서 실행 코드를 정리하고 있습니다.
자그마한 코드 수정으로 인하여 2회 정도 블로그의 웹페이지 로딩 속도가 눈에 띄게 좋아지는 경험을 하였습니다. 정확한 전문적인 정보에 의한 수정 작업이 아니기 때문에 조금씩 공부하고 있는 입문자의 경험담이라 생각하시면 됩니다.
웹페이지 로딩 속도는 구글의 측정 사이트에 MS 엣지 혹은 구글 크롬 웹 브라우저로 접속하여 측정한 것입니다.
인터넷을 거쳐서 블로그에 접속하면 블로그 서버에서는 페이지 코드를 담은 데이터를 일정한 과정을 거쳐서 전송하고 웹 브라우저가 이 코드를 받아 CPU, GPU, 메모리 등의 연산 작업을 거쳐 스크린에 렌더링 하는 것이기 때문에 측정 수치는 웹 브라우저 및 PC(기타 기기)와 전적으로 관련이 있습니다.
구글 측정 서버에서는 측정 대상 도메인(블로그)의 데이터를 받아서 화면에 렌더링하기까지의 전반적인 항목을 계산하여 성능 수치를 제공하는 것이기 때문에 사용자의 웹 브라우저와 PC(기타 기기)는 변수에서 제외됩니다. 간단하게 요약하면 구글 측정 서버와 웹 브라우저가 이를 대신한다고 생각하면 됩니다. 그러므로 사용자의 인터넷 환경도 성능 수치와 관련이 없습니다.
데이터를 받아서 화면에 그 결과를 제시하는 렌더링까지의 소요 시간이 성능 수치라고 정의할 수 있습니다.
1. CSS 파일에 ID와 Class를 설정할 때 정확하게 계층 구조 명시
얼마 전 제 블로그에 "구글 Page Speed Insights 웹페이지 속도 측정"이란 글을 등록한 적이 있습니다.
제 블로그의 모바일 로딩 속도가 동일한 조건에서 20 ~ 31 정도입니다.
오늘 CSS 파일에 정의된 Class 계층 구조를 살펴보고 생략된 항목을 발견하여 이것을 수정 반영한 것이 위 이미지의 수치입니다. 모바일 31에서 47로 상승하였습니다.
- 수정 전 코드
/* Drop-down Menu */
.dropdown { }
.dropbtn, .dropdown-content { }
.dropbtn { }
.dropdown-content { }
.dropdown-content::before,
.dropdown-content::after { }
- 수정 후 코드
/* Drop-down Menu */
.dropdown { }
.dropdown .dropbtn, .dropdown .dropdown-content { }
.dropdown .dropbtn { }
.dropdown .dropdown-content { }
.dropdown .dropdown-content::before,
.dropdown .dropdown-content::after { }2개를 비교하면 ".dropdown" parent Class의 유무 차이밖에 없습니다.
전문적인 지식을 갖고 계신 분이라면 그러한 수치 차이는 당연한 것이라고 하겠지만, 이 원본 코드를 유명한 코드 전문 사이트에서 참고하여 약간의 수정 작업만 거친 것이기 때문에 믿음을 갖고 문제없이 몇 개월을 사용하다가 오늘 로딩 속도 측정을 하고 발견한 것입니다.
웹 브라우저가 HTML, CSS, JS 소스 파일을 전송받아서 프로세싱 할 때 ".dropdown" Class를 임시 메모리에 올린 전체 데이터베이스에서 검색하는 시간이 추가로 소요되었기 때문일 것입니다. 코드의 길이가 약간 늘어나지만 단순한 텍스트이기 때문에 용량 증가는 무시해도 됩니다.
2. 추가적인 연산 과정을 요구하는 %, auto 등의 지정 방법보다는 정확한 수치 사용
블로그 하나의 페이지를 여러 개의 블록으로 나누어 편집 디자인할 때 블록 간의 거리나 가로와 세로 크기 등을 정하여 수치로 환산합니다.
이때 편집자가 편하게 사용할 수 있는 단위가 %와 auto입니다. 하나 더 추가하면 "calc()"도 있습니다.
CSS로 absolute 위치 속성을 사용하여 가로의 중간에 element를 놓고 싶을 때 자주 사용하는 코드가 있습니다.
left: 0;
right: 0;
margin: 0 auto;
혹은 아래 코드를 사용합니다.
left: 50%;
transform: translateX(-50%);
이 방법은 정확한 수치로 지정을 할 수 없기 때문에 어쩔 수 없이 사용하는 것입니다.
이것 외에 정확한 수치를 지정할 수 있는 요소인데 일시적인 코드의 단순함 혹은 편리성 그리고 추후 변동 가능성을 고려하여 %나 auto를 선호하는 경우가 많습니다.
이 막연한 수치 지정인 %나 auto를 배제하고 10px와 같은 확실한 수치를 지정하여 페이지 로딩에 소요되었던 2~3초가량의 랙을 제거하였습니다.
그리고 스킨을 수정하면서 로딩 시간을 측정하니까 "margin: auto;"보다 "calc();" 가 로딩 시간을 단축합니다.
이런 결과를 예상하지 않고 코드를 수정했다가 우연히 얻은 성과입니다. 연결된 파일의 숫자도 많고 코드의 길이가 무자비한 포털 사이트 같은 경우가 아니고 개인 블로그 정도의 크기라면 많은 노력을 필요로 하지 않으니까 테스트하기 적당할 것입니다.
1과 마찬가지로 웹 브라우저의 추가 연산을 요구하지 않는 코드를 사용한 것입니다.
댓글