제목은 렌더링 속도를 끌어올린다고 사기(?)를 쳤지만, 사실은 약간 빠르게 느껴지게 하는 튜닝 정도라고 이실직고하고 시작합니다. ㅎㅎ 이론적인 배경을 설명하는 내용이 조금 긴데, 빠르게 결과만 따라해 보시려거든 '3. 튜닝을 위한 고급 설정 페이지 접근'부터 읽으시면 되겠습니다.
1. 서론
제게 파이어폭스(이하 Firefox)는 꽤 오래 사용해온 손에 익은, 쓰기 편한 단 하나의 웹 브라우저입니다. 나름 웹표준에 가까운 화면을 보여주고, UI 구성이나 사용방법 등 부족할 것이 별로 없습니다. 다만, 최근 흐름에 뒤쳐지는 (가끔 느끼는) 다소 느린 웹페이지 렌더링 속도, 이건 맘에 안들어요.
사실, 크롬(이하 Chrome)이 등장하기 전까진 Firefox 역시 빠른 웹 브라우저였습니다. Internet Explorer(이하 IE)에 비해선 월등히 빨랐거든요. 그러다, 기존 웹브라우저와는 목표점부터가 다른 Chrome이 등장하면서 판세가 뒤집어지기 시작합니다. Chrome이 가볍고 빠른 웹 브라우저의 전형을 보여줬고, 시장 점유율이 쪼그라 들어가던 IE는 IE11이나 Edge 등으로 이에 대응하기 시작합니다. 하지만, Firefox는 적당한 대응시기를 놓치고 말았습니다.
웹 브라우저의 실행속도 자체는 메이저 브라우저 셋 다 고만고만한 수준입니다만, 연산된 결과를 화면에 뿌려주는 렌더링 속도는 Firefox가 적어도 30% 정도는 느리다고 생각됩니다. 즉, 사용자가 체감하는 성능면에선 단연 꼴찌라고 할 수 있습니다. 사실 이 체감속도 자체도 크게 의미가 없긴 해요. 워낙 짧은 시간에 이뤄지는 작업이다보니 크게 체감이 안될 수도 있습니다. 결과물이 나오기까지 1초가 걸리는 것과 1.5초가 걸리는 것은 수치상으론 무려 50% 차이지만, 실제 시간으론 0.5초 밖에 안되거든요.
2. 파이어폭스가 느리게 느껴지는 이유
Chrome의 경우, 기본적으로 Multi-process 그러니까 여러 개의 프로세스(실행파일이 메모리에 올려져 실행되는 상태)를 가지고 동작하는 방식으로 만들어져 있습니다. 최근 다중코어 CPU의 이점을 누리기 적합한 구조라고 볼 수 있습니다.
위 그림이 탭 2개를 열어놓고 작업 중인 Chrome의 프로세스 목록입니다. 메인 창을 관리하는 메인 프로세스 외에도 백그라운드에서 돌아가는 프로세스가 5개나 있습니다. 이건 웹 브라우징 탭 2개와 그에 부속된 Adobe Flash Player 같은 플러그인이 돌아가는 별도의 프로세스 등을 다 따로 떼어놔서 그렇습니다.
멀티탭 웹 브라우저에서 이런 멀티 프로세스 구조의 장점이라면 탭 하나가 오류를 일으켜도 그 탭(프로세스)만 죽일 수 있기 때문에 웹 브라우저 전체가 죽는 참사를 피할 수 있습니다. 또, 요즘처럼 CPU 코어가 여러 개인 상황에선 각 프로세스가 각각의 CPU 코어에 분산되어 작업 속도가 월등히 빨라질 수 있습니다.
누군가는 이런 장점이 많은 구조를 Firefox는 왜 따라하지 못하는건가라고 묻겠지요? Firefox 자체가 개발역사가 너무 오래된 웹 브라우저입니다. 그 모태는 아재 아니면 기억도 못할 Netscape Navigator 거든요. 이미 만들어놓은 기반이 너무 방대하기 때문에 기본설계를 바꾸는 작업 자체가 결코 간단하지 않습니다. 또한, Mozilla 재단 특유의 느린 상황판단도 한몫했을테고요.
이 긴 설명의 단촐한 결론은 '뭔짓을 해도 현재 상태에선 Chrome보다 빠를 수 없다' 입니다. ㅎㅎ
현재 Firefox 역시 Multi-process 구조로 바꾸는 작업을 진행 중에 있고, 그 초기 결과물이 2017년 상반기 중에 나올 예정이라고 합니다. 이 시기는 되어야 최근 Firefox 사용자들이 느끼고 있는 답답함이 어느 정도 해소될 것으로 보입니다. 자세한 내용은 아래 페이지를 참고하시길...
Multiprocess Firefox (https://developer.mozilla.org/en-US/Firefox/Multiprocess_Firefox)
3. 튜닝을 위한 고급 설정 페이지 접근
튜닝은 Firefox의 주소입력줄에 about:config 를 입력하면 나타나는 세부설정을 변경하는 방식으로 이뤄집니다.
처음 주소칸에 about:config 를 입력하면 위와 같은 경고화면이 나타납니다. 고급설정을 잘못 바꾸면 안정성, 보안, 성능에 문제가 될 수 있다는 경고문구. 그 아래의 체크박스를 해제하고 수락 버튼을 누르면 다음엔 이 경고창이 나타나지 않습니다.
고급설정 화면에서 Search 칸에 설정이름의 일부를 입력하면 해당 설정을 빠르게 찾을 수 있습니다.
설정 항목을 더블클릭하여 설정값을 바꾸거나 마우스 오른쪽 버튼을 누르면 나타나는 컨텍스트 메뉴(팝업 메뉴)의 Reset 항목을 선택하여 변경했던 값을 초기값으로 되돌릴 수 있습니다. 애초에 존재하지 않았던, 사용자 임의로 입력한 항목을 리셋시키면 Firefox가 재시작될 때 삭제됩니다.
4. 이미지 Placeholder 기능 끄기
요즘 대부분의 웹 브라우저는 이 기능이 기본적으로 꺼져 있습니다만, 무슨 이유에선지 Firefox는 아직 이 기능을 켜두고 있습니다. 웹 페이지가 로드될 때, 전체를 다 읽어온 후에 화면에 렌더링하는 것이 아니라, 읽어들인 부분적인 내용부터 처리해서 화면에 그려준(렌더링) 후, 내용을 받아오는 순서대로 점진적으로 전체 페이지를 완성해 나갑니다. 이때, 크기가 큰 그림 파일은 웹서버로부터 읽어오는데 오랜 시간이 걸리므로, 그림 파일이 들어갈 위치만 마크해 두고 나머지 부분부터 처리합니다. 이렇게 이미지가 들어갈 자리에 빈 틀을 넣어서 마킹하는 것을 Image Placeholder라고 부릅니다.
이 기능의 장점이라면 웹서버와의 전송이 원할하지 못할 경우, 받아오지 못한 그림 파일이 있다는 것을 쉽게 알아챌 수 있다는 것과, 그림 파일을 나중에 렌더링하더라도 그림이 들어갈 위치를 잡아뒀기 때문에 레이아웃을 재조정해야 하는 작업을 피할 수 있다는 정도입니다.
인터넷 속도가 느리고 컴퓨터도 속도가 느리던 옛날엔 이 기능이 유용했습니다만, 현재는 꼭 그렇지도 않습니다. 인터넷 속도 자체가 워낙 빠르고, CPU의 연산속도 또한 비약적으로 발전해서 레이아웃을 재조정하는 시간이 그렇게 오래 걸리지 않습니다. 오히려 Placeholder를 처리하는 단계를 없애버리는 게 전체적인 렌더링 속도를 올릴 수 있습니다.
about:config 에서 browser.display.show_image_placeholders 의 설정값을 fasle로 변경합니다. 기본값은 true 상태.
5. 렌더링 대기시간 없애기
웹 서버에서 받아온 내용을 화면에 나타내려면, 인터넷을 통한 데이터 전송이 필수적입니다. 이 때 걸리는 시간을 감안하여 설정된 초기 대기시간이 있습니다. 내부적인 기본값은 250ms(0.25초)입니다. 즉, 그 이전에 일부 데이터가 도착했더라도 0.25초 동안은 렌더링을 하지 않고 대기한다는 의미입니다.
nglayout.initialpaint.delay 항목에서 새 대기시간을 지정할 수 있는데, 기본적으로 존재하지 않는 항목입니다. 따라서 설정 항목 자체를 새로 만들어줘야 합니다. 아래 그림처럼 integer 항목을 만든 후, 이름은 nglayout.initialpaint.delay 를 입력하고, 값은 0을 입력합니다.
6. 웹서버와의 네트워크 연결 개수 늘리기
보통 웹 서버와 웹 브라우저 간의 네트워크 연결은 여러 개를 열어두고 사용합니다. 웹 페이지 하나에 부속된 파일이 많아질 수록 한 파일을 받고 다음 파일을 받기까기 대기하는 시간이 늘어나게 됩니다. 따라서, 네트워크 연결을 여러 개 열어두고 사용하면 동시에 여러 파일을 받을 수 있습니다. 그 결과, 많은 수의 파일을 받을 때 발생하는 대기 시간을 줄일 수 있게 됩니다.
network.http.max-persistent-connections-per-server 항목에 이 값을 지정하는데, 기본값은 6입니다. 이걸 8로 바꿔주면 웹 서버와의 네트워크 연결이 최대 8개까지 유지됩니다. 단, 사용자가 아무리 큰 값을 지정하더라도 웹 서버쪽에서 한 클라이언트 당 최대 연결수를 제한하면 이 설정은 아무 의미가 없게 됩니다. 따라서, 이 설정은 웹 서버쪽에서 많은 연결을 허용한 경우에만 그 효과가 나타나게 됩니다.
최근 웹 브라우저에서 사용하는 이 값의 범위는 4~8 정도입니다.
7. 튜닝의 결과
여기까지 설정했다면 자주가는 웹사이트에 접속해서 페이지가 뜨는 속도의 차이를 느껴보세요. 약간 빨라진거 같죠? 하지만, 이 글의 시작에서 언급했듯이 실제 렌더링 속도가 빨리진 것이 아니라, 렌더링이 시작되는 시점이 약간 빨라졌을 뿐입니다. 한마디로 빨리진 것처럼 보이는 트릭일 뿐입니다.
자주 가는 Daum 뉴스 페이지인 http://media.daum.net를 방문하여 튜닝 전후의 로딩 시간를 재어보면 아래와 같습니다.
튜닝 전후, 페이지 로드에 각각 1.72초와 1.67초가 걸렸습니다. 약간의 차이는 여러 요인에 의해 발생하는 통상적인 오차로 성능에 의미를 두기 어렵습니다. 하지만, 렌더링이 시작되는 시점이 앞당겨진 탓에 약간 빨라진 듯한 착시를 일으킵니다.
절대, 기본적인 성능에는 변함이 없다는 것을 확인하기 위해 BASEMARK Web 3.0과 Peacekeeper 벤치마크를 돌려봤습니다.
Peacekeepr 결과는 튜닝 전후로 4320 ▶ 4232점, Basemark 결과는 159 ▶ 151점을 기록했습니다. 튜닝 후 약간 하락한 것으로 보이지만, 오차범위 내의 무의미한 결과입니다.
예상보다 글 내용이 길어지고 말았네요. 나머지는 다음 포스트로 나누어 쓰도록 하겠습니다.
'컴퓨팅 > 소프트웨어' 카테고리의 다른 글
| 파이어폭스 51, 멀티-프로세스(e10s) 강제 활성화 (4) | 2017.01.24 |
|---|---|
| 웹 브라우저, 파이어폭스 렌더링 속도 끌어올리기 2/2 (8) | 2016.11.14 |
| Windows 10 KB3189866, KB3185614 업데이트 오류 해결 (8) | 2016.09.14 |
| Windows 10 1607에서 사라진 스티커 메모(WIN32 Sticky Notes) 복원하기 (38) | 2016.08.10 |
| fre:ac - CD 립핑, 오디오 파일 변환툴 (0) | 2016.04.23 |