크롬(웹 브라우저)/문제점

덤프버전 : r20190312

파일:나무위키+상위문서.png   상위 문서: 크롬(웹 브라우저)

1. 개요
2. 문제점
2.1. ERR_RESPONSE_HEADERS_MULTIPLE_CONTENT_DISPOSITION
2.2. 자동종료 문제
2.3. 성능상의 문제
2.4. 기능상의 문제
2.5. 개인정보 문제
2.6. '제목 없음' 오류 시 해결방법
2.7. 타 브라우저보다 유튜브가 더 끊길 때
2.8. 0x80004002가 뜨며 설치가 안 될 경우
2.9. macOS 성능 문제
2.10. 기타
3. 버그가 아닌 것들
4. 메모리 문제 (해결)


1. 개요[편집]


웹 브라우저 크롬의 문제점을 서술해 놓은 문서다.

2. 문제점[편집]



2.1. ERR_RESPONSE_HEADERS_MULTIPLE_CONTENT_DISPOSITION[편집]


가장 심각한 문제점. 어떤 파일을 다운로드하려 시도할 때 파일명에 comma(,)가 포함되어 있으면 "ERR_RESPONSE_HEADERS_MULTIPLE_CONTENT_DISPOSITION"라는 오류가 뜨면서 파일이 다운로드되지 않는 오류가 있다. 2012년부터 지금도, 무려 6년 넘게 발생하고 있는 오류임에도 구글 측에서는 아무런 조치를 안 하고 있다.

2.2. 자동종료 문제[편집]


  • 68 버전 업데이트 이후 크롬이 사용중에 자동종료되는 버그가 다수 보고되고 있다. ctrl+shift+Q 누르셨어요?

  • 메모리가 남아도는 쾌적한 상황에서도 자주 발생하기 때문에 메모리 관리 문제로 볼 수는 없다.

  • 구글 측에서 해당 문제에 대해서 인지하고 있는 것 같으나 개선이 전혀 되지 않고 있다.

  • 해당 증상에 시달린 많은 사용자들이 파이어폭스 및 엣지 브라우저 등으로 넘어가고 있는 상황.

  • 해외 개발자에 의하면 ~64 버전까지는 해당 증상이 보고되고 있지 않다고 한다.

2.3. 성능상의 문제[편집]


  • 일부 이미지가 로딩되지 않는 문제.

  • 애니메이션 gif 로딩 속도 문제 - 다른 브라우저와 비교할 것 없이 크롬 자체만 보아도 확연히 알 수 있을 만큼 티가 난다. 5초짜리 gif 플레이에 30초가 걸리는 경우도 있다. 다만, '첫 로드'시에만 그렇고 두 번째 부터는 정상 속도로 돌아간다.

  • 야후! 플리커의 피크닉 서비스 사용불가(매우 느림). 어차피 한국 에서는 안쓴다

  • 넷북같이 사양이 떨어지는 PC에서 그림이 많은 페이지를 볼때 심각하게 느리다. 스크롤이 너무 심하게 끊기고 로딩이 늦다. GPU 가속기능을 켜도 나아지질 않는다. 파이어폭스에서는 볼 수 없는 현상이다. 또한 그림이 바로바로 로딩되지 않아서 스크롤을 올리고 내릴 때마다 흰색상자 같은 것이 깜빡깜빡거리는 현상도 나타난다.

  • 전력 소모가 큰 편으로 알려졌다. 이것이 버그인지 아닌진 모르지만, 노트북이나 태블릿의 경우 그렇게 달갑진 않은 부분. 그러나 구글은 버그 리포트에서 이 부분을 전달받고도 무시한 것으로 드러났다. 구글은 수년이 지나서 포브스에서 관련 기사가 보도된 후에야 수정하겠다고 밝혔다.

  • 플래시 비디오를 볼 때 수직동기화를 지원하지 않는지 간헐적으로 가로줄이 발생한다.

  • 모바일용 크롬 61 기준 일부 저사양 스마트폰에서 장시간 웹서핑을 하면 화면이 까맣게 되는 버그가 생긴다. 새로고침을 해도 해결이 안된다. 해결책은 크롬을 강제종료하거나 해당 탭을 닫았다 다시 열거나 아래로 스크롤하면 풀리기도한다. 게다가 사용 중에 먹통이 되는 경우도 있다.

  • 일부 저사양 스마트폰에서 크롬을 통해 유튜브 영상을 보고 있으면 화면이 깨지는[1] 현상이 발생한다. 화질이 자동으로 변환될 때 주로 발생하는데,[2] 이럴 때는 전체화면 또는 창모드로 전환하면 해결된다. 하지만 이게 한번 발생하고 끝이 아니라서 화면 깨질 때마다 해줘야 한다.

2.4. 기능상의 문제[편집]


  • 프린터나 문서에 따른 인쇄 옵션을 저장할 수 없다. 또한 프린트시에 자체 프린터 인터페이스를 제공하는데, 인쇄 옵션에서 설정할 수 있는 기능이 적다.

  • 히스토리 자동 삭제 기능이 없다. 다만 Click & Clean과 같은 부가기능으로 대체할 수는 있다.

  • 번역 기능이 딥러닝 기술이 적용되지 않아 개판으로 번역된다. 게다가 번역 기능이 어떤 사이트에서는 뜨고 어떤 사이트에는 안 뜬다. 게다가 2017년 들어서는 구글 번역기 서버의 부하를 줄이기 위해서 인지 해당 문서를 로딩할 때 전부 번역하지 않고, 브라우저 창에서 스크롤하는 만큼만 실시간 번역해서 보여주는 방식으로 바뀌었는데, 전보다 불편할 뿐 아니라, 번역되었다가 다시 원문으로 돌아갔다가 하는 등 번역문 출력 기능 자체가 불안정해졌다. 그리고 2018년 4월 기준으로 일부 PC 유저들에게 자동번역 아이콘이 나오지 않는 현상이 발생하였는데, 일부 언어는 자동번역 아이콘이 뜨기도 하고 안 뜨기도 한다.[3][4] 이 현상은 현재까지 해결되지 않고 있다.

  • 파일:chromemanytab.png
탭을 많이 열어놓고 쓰는 사용자에게는 크롬이 오히려 불편해진다. 우선 위에서 말한 메모리 사용량 때문에 사실 탭을 많이 열고 쓰는 것도 힘들고, 또한 많은 탭을 한 줄에 다 끼워넣으려다 보니 페이지 제목이 보이지 않는 수준까지 가기도 한다. 파폭은 이런 쪽에 신경을 매우 많이 쓰는 편이다. 기본적으로 메모리 사용량도 매우 적고, 탭이 아무리 많아도 탭 타이틀을 일정수준 이상 표현해주며, 모자라는 공간은 탭 스크롤을 기능을 이용하여 마우스 휠로 간단히 찾아볼 수 있게 했다. 거기 더해서 각각의 탭을 디렉토리처럼 정리 가능한 파노마(탭 그룹) 기능까지 추가해서 거의 완벽에 가까운 지원을 보여준다. 크롬에서는 탭 그룹 기능을 제공하지 않고 있다. 탭 그룹 기능의 부재를 이유로 크롬에서 파이어폭스로 돌아가거나 크롬으로 옮겨가지 않는 유저들도 있다. 반면 크롬에는 파이어폭스에 없는 탭 선택 기능이 있다. 파이어폭스는 크롬처럼 탭을 하나씩 뜯어서 다른 창으로 만들 수 있지만, 크롬의 경우는 Ctrl 키로 개별 선택을 하거나 Shift 키를 사용해서 A부터 B 까지 탭을 선택한후, 한번에 뜯어서 다른 창으로 만드는 기능이 있다. 즉, 웹 페이지의 카테고리에 따라 각각 다른 창으로 탭 묶음을 만들어 정리할 수 있는 기능이 있다. 물론 사용자의 특성에 따라 호불호가 갈리는 기능이다. 파이어폭스식으로 한 창에 모든 탭을 정리하는게 편하다는 사람도 있고 크롬처럼 그룹을 만들어서 정리하는 방식이 편하다는 사람도 있다. 크롬의 탭 겹치기 기능은 사라졌다.
파일:R3BaXo7.png
탭 뜯어내기 예제

  • 즐겨찾기, 즉 북마크를 왼쪽 사이드바에 넣는 기능이 없다. 일부 IE를 쓰던 사람이 크롬을 사용하면 불편하게 느끼는 것 중 하나로, 아무래도 과거 브라우저들의 북마크가 좌측에 있기 때문에 자연스럽게 그 쪽을 찾는 게 버릇이 되어서 그런 듯하다. 대신 주소표시줄 밑에 북마크를 항상 표시할 수 있게 하는 "북마크바"라는 기능이 있다. 북마크를 폴더 안에 넣어놨다면 풀다운 메뉴와 유사하게 동작하는 것이 특징이다.[5] 단축키는 CTRL+Shift+B.프로그램 빌드하냐?

  • 북마크를 좌클릭으로 새 탭 전경으로 여는 기능이 없다. 옵션으로도 없고, 확장기능으로도 없다. 검색도 마찬가지.. 변종 크롬 브라우저에선 대부분 지원한다. 북마크를 드래그해서 탭 사이나 비어있는 공간에 놓으면 새 탭으로 열린다. 이게 아니라도 Ctrl+클릭이나 휠클릭으로도 가능하다. 그냥 좌클릭으로 안되는게 문제지..

  • Windows 8.1을 사용하는 일부 시스템에서 'Windows 8.1 모드에서 Chrome 다시 실행'을 누르고 Windows 8.1모드에서 글을 쓸 때 스페이스 바나 마침표, 쉼표와 숫자 키보드 등을 누르면 그 전에 쓰던 단어가 추가된다. 이게 무슨 말이냐면,
이러한 이러한버그가 튀어 나왔을때 나왔을때수정 수정안하고 그대로 그대로썼을 썼을경우 이같은같은 문장이 나오게 되되는 것이다.[해석] 이렇게 일정한 확률로 글을 쓸때 뒤의 단어가 또 써지는 버그가 있다.

  • 투명이 적용된 PNG 이미지를 '이미지 복사'해서 포토샵이나 그림판에 붙여넣으면 투명한 부분이 검은색으로 변한다. 중간 어딘가에서 알파 값이 소멸되는 듯. 파이어폭스는 이런 일이 없다.

  • 2014년 10월 8일에 업데이트된 38.0.2125.101 버전에서는 한국어 로케일에서 일본어, 중국어로 된 웹 사이트에 접속시 탭 영역, 북마크, 검색창 등에서 표시되어야 할 한자(간체자와 번체자, 일본식 한자 전체)와 일본어 특수문자(ー, ・・・ 등)들이 전부 깨져버리는 버그가 발생하였다. 또한 일본어 로케일에서는 반대로 일본어에 없는 한자들과 한글이 전부 'ㅁ' 으로 깨져나간다. 외국어 로케일이나 외국어로 된 OS를 사용하거나 해외 사이트 접속이 잦은 이용자들에게는 상당히 치명적인 버그로, 심한 경우에는 자국어도 제대로 표시되지 않는 케이스도 보고되고 있다. 북마크나 탭 영역이 전부 깨져나가 인식할 수 없게 되는 것도 불편하지만 이 버그의 가장 큰 문제는 주소창이나 검색창, 북마크 입력시 한글/일본어/한자 입력 등이 전부 ㅁ로 나온다는 것. 입력 자체는 가능하며 입력한 데이터에도 문제는 없다. 그냥 표현만 ㅁ로 되는 것일 뿐이다. 실제로 ㅁ로 나오는 것을 복사한 다음 크롬이 아닌 다른 곳에 붙여넣기 해보면 값은 정상적인 것을 확인할 수 있다.(링크) 다만 모든 환경에서 발생하는 버그는 아닌 것으로 알려졌다. 38.0.2125.111 버전에서 이 문제는 해결됐다고는 하지만 여전히 일부 사양에서는 다음과 같은 오류가 발생한다. 또한 한글 입력시 커서가 문자의 우측이 아니라 좌측에 입력되는 현상이 있다.

  • 가끔씩 탭을 클릭하다 보면 탭이 꺼지는 버그가 있다. 탭을 이동할 때도 가끔씩 탭이 꺼진다.

  • 최근에 파이어폭스는 부가 기능 없이도 읽기 모드를 지원하는데, 크롬은 그런 거 없다. 이 부가기능을 설치하면 되기는 한다.[6]

  • 44.0.2403.155m 또는 45 beta 버전 기준 windows 10 환경에서 위에서 언급된 한자, 일본어 특수문자 등이 깨지는 상황이 발생하는 문제가 발견되었다. 임시 방편으로 크롬 브라우저에서 chrome://flags를 치고 Directwrite를 사용 중지를 체크하면 해결할 수 있다.

  • 44.0.2403.157 m 기준으로 새 탭 섬네일이 8개에서 6개로 줄어드는 현상이 있다. 해결방법은 ctrl+0 또는 ctrl + 동시에 누르라고 답변이 되어 있으나 임시적인 해결 아니면 아예 해결 자체가 안되는 경우가 있다.

  • 윈도우에서 크롬 45 버전으로 업데이트하면 Comodo와 충돌을 일으켜서 실행이 안 되는 문제가 있다. 아무런 에러 메세지도 띄우지 않고 그냥 죽어버리므로 Comodo를 사용하고 있다면 당황하지 말고 Shellcode injection 옵션에서 chrome.exe를 예외로 추가하라.(참고)

  • HTTPS를 사용하는 웹사이트에 접속하면 ERR_SPDY_PROTOCOL_ERROR를 내뿜으면서 로딩이 안 되는 경우가 있다. 이는 크롬이 자체적으로 사용하는 SPDY 프로토콜[7]에서 에러가 발생한 것으로, 크롬 바로가기 맨 뒤에
    --use-spdy=off --use-system-ssl
    를 넣어서 SPDY 사용을 끄면 정상적으로 접속된다. 구글도 이런 점을 인지했는지 2016년부터 SPDY 사용을 중단하고 HTTP/2로 대체하였다.

  • 버전 20 이하에서 최신 버전으로 업데이트하려고 하면 현재 버전을 최신 버전으로 인식하는 오류가 있다. 이럴 때에는 크롬을 삭제한 다음 새로 설치해주자.

  • 52.0.2743.82 m 기준으로 해당 위키를 포함하여 몇몇 사이트 폰트가 깨알같이 작게 나오는 버그가 있다. 크롬 실험실에 있는 direct write 삭제가 원인. 해외 쪽에서도 이슈가 됐으니 확대해서 페이지를 보거나 새 버전을 기다리거나 구글 그룹스에 해당 이슈 글을 올리는 방법밖에 없다.

  • 멀티 모니터 환경에서 윈도우 10 HiDPI 모니터 Scale 옵션 미적용 문제.[예시] 이는 크롬이 DPI-Aware로 설계되어서 발생한 문제로, Per-Monitor 방식으로 재설계하지 않는 이상 해결이 어렵다.

  • 2016년 10월 19일에 업데이트된 모바일판 크롬 54.0.2840.68 버전에서 이런저런 문제가 발생하였는데, 일부 모바일 기종과 안드로이드 버전에 한해 약간의 버벅임, 이상해진 번역 기능, 좀 오래 쓰다 보면 발생하는[8] 한글 입력 불가,[9] 북마크 실종[10] 등의 문제가 발생했다. 그리고 나무위키 한정으로 일부 긴 문서 제목이 나무위키 레이아웃 바깥의 회색 영역으로 튀어 나오거나 문서 내의 외부링크를 나타내는 초록색 사각형 안의 클립 아이콘과 일부 문자도 이러한 현상을 야기했다. 심지어 이런 현상이 문서에만 국한된 게 아니라 편집창, 이동창, 역사창과 비교창에도 나오는 등... 전 버전에서는 정상적으로 작동되더니만... 아무래도 크롬의 문제인 듯 싶다. 현재는 고쳐졌다.

  • 모바일판 크롬의 경우 어느 시점의 업데이트 이후로 일부 반응형 사이트들의 작동에 심각한 결함이 생겼다. 스크롤링을 하려고 했는데 하이퍼링크가 먼저 터치되어서 이동해 버리는 문제가 발생하기도 하고 몇몇 자바스크립트가 심하게 씹힌다. 웹페이지의 레이어가 더해질수록 버그가 심해지는 경향이 있다.


  • PC 버전의 다양하고 유용한 확장 프로그램들이 많은 반면 이 모든 확장 프로그램들을 모바일 버전에선 쓸 수 없다. iOS·안드로이드 모두 포함해서. 북마크 기능을 포함해 다른 구글 계정 등 모든 게 호환되지만 유독 이것만 호환 안된다. 이 때문에 PC에서 크롬 잘 쓰다가 모바일에서 다른 브라우저로 갈아타는 사람들이 있는데, 대부분 이 경우다. VPN·광고 차단기능을 비롯해 웹사이트의 동영상 다운로드 프로그램 등 상당히 쓸만한 확장 프로그램들이 많았기 때문에 사용자들의 아쉬움은 더 커지기만 하고 있다.

  • 61 버전 이후로 나무위키 편집 시에 미리보기를 하면 악의적인 코드가 있어서 표시를 차단했다는 메시지가 표시되는 경우가 생겼다. 보통 유튜브, 다음팟 같은 동영상이 첨부된 부분을 편집할 때 발생하는데, 이 때문에 복잡한 위키문법을 일일히 봐가면서 꼼꼼하게 편집하거나 아니면 저장했다 틀린 내용이 있으면 또 편집해야 하는 이뭐병스러운 상황이 자주 발생하고 있다.

  • 본래 인터넷 익스플로러처럼 인코딩을 수동 지정하는 기능이 있었으나, 어느 시점부터 업데이트를 통해 기능 자체를 없애버렸다. 이 때문에 인코딩이 지정되지 않은 웹사이트에서는 인코딩이 무조건 완성형(EUC-KR)이나 서유럽어(Windows-1252)로 고정되어서 글자가 깨진다.[11] 또 영어권 웹사이트에서도 확장 아스키 문자(0x80~0xFF)를 사용한 경우 인코딩이 잘못 지정되어서 뷁어물음표꼴로 표시되기도 한다. 물론 인코딩 지정조차 하지 않은 웹 사이트들이 잘못된 것이기는 하지만, 인코딩 지정 기능을 아예 빼버리는 것은 무리수가 아니었을까.

  • 크롬 모바일 72.0.3626.76 버전에서 다른 링크로 이동할 때 웹페이지 대신 검은 창만 표시되는 버그가 있다.
파일:Chrome_72_Problem_2.png
탭 뷰로 나갔다 들어와도 정상화되지 않는다. 그러나 다른 탭을 갔다가 들어오면 정상화된다.
파일:Chrome_72_Problem_1.png
위 사진에서 해당 문제가 발생한 첫 번째 탭(맨 위 탭)은 미리보기가 되지 않고 있다.
나무위키의 경우는 더 심한데, 전체적으로 느려진 데다가(광고 제거 앱이나 부가기능을 쓰면 이러한 현상이 약간이나마 줄어진다) 편집창의 미리보기에 로딩이 생겼고 글자량이 많은 문서일 수록 그 로딩도 더 심해지며 일부 문서와 문서 편집창 자체가 까만 화면이 되어 버려서 다른 탭을 왔다갔다 하면 정상적으로 돌아오는 경우가 많아졌고 자판 치는 속도가 로딩에 걸린 것마냥 느려져 버렸으며 그 때문에 손가락이 빠른 위키러들이 이러한 불편을 겯고 있으며 유튜브 링크 영상의 경우는
[[링크된 유튜브 주소|설명]]
문법에 한해 유튜브 이 아니라 새 탭이 뜨면서 유튜브 으로 들어가는 문제가 생겼다.

2.5. 개인정보 문제[편집]


웹 브라우저 가운데 개인정보와 관련해서 가장 많은 문제점이 야기된 것이 크롬 브라우저이다. 버전 4까지는 크롬 인스톨 시에 브라우저에 유니크한 ID를 부여하여 이 ID와 함께 전송하였기 때문에, 구글 로그인을 안 해도, 누가 무엇을 검색하고 어떤 페이지를 방문하였는지가 모두 기록되었다. 이 기록들은 어떤 광고를 띄울지 결정하는 정보로 대개 쓰였다. 예를 들면, 매독을 검색한 사용자에게는 매독약 광고를 주로 띄우는 등(…). 당연히 이용자들은 들고 일어났고, 그 다음에 쏟아진 비판에 못 이겨 이 기능을 삭제하였다고 발표했다. 이후에도 주소창에 주소를 치면 매 글자 하나하나 칠 때마다 키로거 프로그램처럼 구글에 전송하였다가 마이크로소프트에 걸려 유튜브에 이것이 공개된 적도 있다. 독일 IT 보안국에서는 위와 같은 여러가지 개인정보 수집 문제로 법적 소송까지 고려하고 있다고 거론한 적이 있다.

이외에도 구글 자체가 불법 개인정보 수집으로 여러차례 걸린 적이 있기 때문에, 브라우저와 관련된 일련의 사건들은 개인정보 보안에 민감한 사람들에게 크롬 브라우저뿐 아니라 구글 검색등 구글이 제공하는 서비스들까지 꺼려지는 계기가 되었다. 오죽하면 크롬 웹스토어에 개인정보 추적 방지 웹앱까지 있을 정도. 물론, 오늘날 완전히 구글 검색을 사용하지 않는 것은 무리가 있기 때문에, 이런 사용자들은 대부분 타인에게 보여도 상관없는 정보들만 구글 검색을 이용하고, 민감한 정보들의 경우에는 개인정보 보호가 보다 철저한 DuckDuckGo같은 검색 서비스를 이용한다. 웹앱을 다운받았는데 나무위키에서 하나 떴다

참고로, 이러한 문제들은 크로뮴과는 관련이 없다. 크로뮴은 애초에 누구나 소스를 열람할 수 있는 오픈소스로 개발되고 있기 때문에, 저러한 개인정보에 민감한 코드가 들어갈 여지가 거의 없다. 크롬은 크로뮴의 소스를 구글이 가져다가 여러가지 기능을 더하여 만들어지며, 소스를 공개하지 않기 때문에 저런 식의 개인 정보 수집 패치를 더할 수 있었던 것이다. 하지만, 그런 크로뮴도 개개인을 식별할 수 있을 정도로 UAstring에 쓸모없는 정보까지 전송되어 논란이 되고 있다. UAstring은 원래 브라우저 정보 정도만 전송해서 웹 페이지에서 그에 맞는 서비스를 제공하도록 하는 기능이다.

2.6. '제목 없음' 오류 시 해결방법 [편집]


버전 23으로 업그레이드된 이후 크롬이 '앗! 이런'만 띄우거나, '제목 없음'만 띄우는 경우가 자주 발견됐다. 원인은 suachm.exe라는 프로세스 때문으로, 이 경우 프로세스를 종료시키고 C:\Program Files\\AlphaDRM(윈도우 7 64 비트는 C:\Program Files (x86)\\AlphaDRM)을 삭제해주면 정상적으로 작동한다. 이 방법도 안 먹힌다면 바로가기 속성에서 '대상'란 맨 끝에 띄어쓰기 하고 -no-sandbox를 입력하면 해결가능하다. 아니면 호환성 탭을 클릭해서 호환모드를 자신이 쓰는 운영체제로 바꾸어 준 다음 관리자 권한으로 실행 체크를 해제해주자. 애초에 체크가 되어있지 않다면 호환모드만 바꿔주자. 위에 방법도 소용이 없다면 백신 프로그램으로 정밀검사를 시도해보자. 혹은 DNS를 구글 퍼블릭 DNS인 8.8.8.8이나 8.8.4.4로 바꾸면 잘 작동하기도 한다. C:\\Users\\(사용자 이름)\\AppData\\Local\\Google\\Chrome\\User Data\\Default\\Local Storage 폴더 내부의 파일들을 전부 삭제해주는 것도 방법이다.

2.7. 타 브라우저보다 유튜브가 더 끊길 때 [편집]


2014년/2015년경부터 저사양 컴퓨터에서 유튜브 감상시 크롬(또는 웹키트 엔진 계열)으로만 끊기는 현상이 조금씩 이슈화되고 있다. 이는 구글이 지원 및 개발한 규격인 WebMWebP를 밀어주고 있기 때문으로 크롬으로 유튜브 영상을 재생하면 대부분 WebM 컨테이너에 VP9 코덱으로 재생되며, 재생 목록의 스틸 컷 등의 그림 파일들은 모두 WebP로 나온다.(미지원 브라우저에서는 H.264 코덱와 MP4 컨테이너, 그림파일은 JPG를 사용한다) VP9은 기본적으로 H.265와 경쟁하기 위하는 코덱인지라 H.264보단 무거운 편인 데다가, 그래픽 카드와 브라우저가 함께 하드웨어 가속을 지원하지 않으면[12] 소프트웨어 디코딩을 해야 하므로 저사양에서 문제를 일으키는 것. 그래픽 카드가 가속을 지원하면 재생이 훨씬 가벼워지지만 그러지 않는 컴퓨터에서는 여전히 문제가 되고 있다.

이 문제를 해결하기 위해 WebM 지원을 강제로 막아 H.264로 재생(컨테이너는 MP4)하게 해주는 확장 기능을 냈다.[출처2] 타 브라우저에서의 H.264 가속은 문제가 없는 환경이라면 더욱 효과적이다. 다만 이 상태로 유튜브 동영상을 감상하면 1440p 60 옵션이나 2160p 60 옵션이 사라지기에 1080p 60이 60프레임으로 재생할 수 있는 최고 옵션이 되는 점을 감안해야 한다.[13]

이 문제는 브라우저나 코덱 자체의 결점이라기보단 아직 VP9이 최신 코덱이다 보니 겪게 되는 불편함이라,[14] 앞으로 VP9 지원 환경이 차차 정착되면 자연스레 해결될 수도 있다. 다만 구글의 뜻대로 그렇게 될지는 계속 지켜볼 일.[15]

여담으로, WebM을 지원하지 않는 IE같은 타 브라우저에는 이런 문제가 없다.

비 웹키트 브라우저 가운데 WebM 지원이 가장 좋다고 할 수 있는 파이어폭스는 48버전 기준 Media Source extensions(MSE)[16]WebM 지원 둘 다 기본적으로 활성화되어 있지만, MSE에서 WebM을 쓰는 옵션은 여전히 about:config에서 수동으로 켜 줘야 된다(쉽게 말해서 둘 중에 하나만 쓰는 건 잘 되는데, 둘 다 동시에 쓰는 건 아직 버그를 다 못잡아서 기본값 Off로 막아놨다는 뜻).] 55 버전으로는 잘 된다.[17]

엣지의 경우 레드스톤 업데이트 이후로 MSE와 함께 정식 지원된다. 오히려 크롬보다도 더 잘 지원한다는 평이 많다(같은 사양에서 같은 영상 재생시 CPU점유율 확인[18] 등 비교해보면 크롬 < 파폭 < 엣지 정도의 평이 많이 나온다. 이는 18년 6월 현재에도 유효한 편).

기본 설정에서는 VP9의 하드웨어 가속을 할 수 있는 환경인지를 확인하여 할 수 있으면 VP9으로, 못 하면 H.264로 재생된다. about:flag로 들어가면 그래픽 카드의 가속 지원 여부와 관계없이 VP9에 대한 MSE 사용을 강제하거나 차단할 수도 있다.

브라우저의 지원 여부는 https://www.youtube.com/html5에서 간단히 확인할 수 있다. 요것만 테스트해 봐도 유튜브 지원 한정해선, 필요한 모든 것을 알아볼 수 있다(윗줄만 지원되면 720p 30프레임까지만 볼 수 있고, 아랫줄까지 지원해야 4K 60 프레임 영상까지 100% 다 볼 수 있다).[출처1]

2.8. 0x80004002가 뜨며 설치가 안 될 경우[편집]


현재 사용하고 있는 브라우저 말고 다른 브라우저를 써서 다른 위치(ex: 내 문서)에 다운받아 설치하면 해결된다. 여담으로 이 문제점은 구글이나 네이버에 검색해도 해결 방법이 잘 검색되지 않았다. 레지스트리 삭제는 아예 먹히지 않는다는 사람도 많다고 한다.

해결법은, 구버전 셋업 파일 설치 후 브라우저 설정 초기화를 하면 해결된다.

2.9. macOS 성능 문제[편집]


macOS 에서는 윈도우 버전 크롬보다 자잘한 버그가 더 많고 성능도 떨어진다. 웹페이지가 갑자기 멈춰버린다던가 일부가 로딩이 안 된다던가 사소한 문제점이 많다. 맥북 등 노트북에서는 다른 브라우저보다 배터리를 더 빠르게 소모하며, 확장 프로그램을 많이 달거나 스트리밍 서비스를 이용하는 등의 활동을 하면 순식간에 밑바닥이 뜨거워진다. 대표적인 예가 이런 확장 프로그램.

그래도 67 버전에 와서는 macOS에서의 배터리 소모량 등이 크게 개선되었다.

2.10. 기타[편집]


  • 포털 사이트 네이버블로그에서 '표'를 제작할 때 특정 환경에서는 꽤나 쓰기 번거롭다. 표 도구를 자주 활용하는 사람은 페이지에 표를 먼저 놓고 아래위로 여백을 마련해 글을 쓴다거나 하는 등의 작업이 잦은데, 크롬에서는 이와 같은 작업이 썩 편리하지만은 않다.

  • 크롬에서 swf 파일을 실행하려고 하면 자동 다운로드로 넘어간다.# 구글에서 고치지 않겠다고 결정한 문제이기 때문에 웹사이트에서 swf 파일을 실행하려면 어쩔 수 없이 다른 브라우저를 쓰는 수 밖에 없다.

  • 2018년 5월 22일부터 구글 크롬에서 구글 검색으로 검색하면 이상하게 ""????(으)로 이동하려고 하셨나요?"" 뜨고 있다. 여러모르 많이 겪고 있다. 그리고 유튜브 버퍼링도 장난이 아니다.[19] 유튜브를 보다 뒤로가기를 했는데 뒤로가기 하기 전에 재생하던 동영상의 소리가 출력된다.

  • 안드로이드 앱에서는 검색창에서 한자 변환이 안 된다.

3. 버그가 아닌 것들[편집]


  • 호환용 한자가 통합 한자로 자동 변환된다. 이것은 문제점이 아닌 장점에 속하기는 하지만, 호환용 한자를 구분해야 하는 상황에서는 문제가 된다. 완성형/중복 한자, 한자/BMP 등의 문서가 그 예시.

  • 네이버 등 일부 사이트에서 é, ö, â 등 diacritic이 붙은 로마자가 그냥 e, o, a가 되는 식으로 자동변환되는 경우가 있어서 문제가 되기도 하는데, 이는 웹사이트에서 유니코드를 지원하지 않아서 발생하는 현상이다. 나무위키처럼 유니코드를 지원하는 사이트들은 크롬으로 편집해도 이 문제가 발생하지 않는 것을 알 수 있다. 인터넷 익스플로러에서 정상적으로 입력이 되는 이유는 유니코드를 지원하지 않는 환경에서 자동적으로 특정 문자들을
    &#xxxx;
    와 같은 식으로 특수 처리하기 때문이다. 즉 유니코드를 지원하지 않는 웹사이트들이 문제이지, 크롬의 버그라고 하기에는 애매하다.

4. 메모리 문제 (해결)[편집]


과거에는 기본적으로 RAM을 많이 먹었던 구조였으며, 탭 하나에 프로세스 1개씩 소모했었다. 그러니 밑줄 안에 있는 내용들은 전부 과거형임을 알아두자.

파일:navpuPi.gif
다른 브라우저들[20]보다 RAM 소비가 엄청난 크롬을 풍자한 움짤.[21]
만약 실제 RAM이 부족하면 1개의 프로세스에 여러 개의 탭을 붙이기 시작한다. 사용중인 램이 실제 RAM보다 많으면 가상 메모리를 사용하는데, 이때부터 탭 전환, 스크롤, 페이지 로딩 시에 다른 브라우저보다 이 많이 걸린다. 단적인 예로 크롬 버전 17 과 파이어폭스 버전 11 메모리 사용량 비교벤치에서 파이어폭스 11은 360MB를 기록한 반면에 크롬은 무려 1.45 GB를 기록했다. 한편, D사의 한 프로그램에서 웹 브라우저끼리 최강자를 뽑는 실험을 했다.

요즘 컴퓨터는 메모리 용량이 많아서 문제가 없다고 생각할 수도 있다. 그러나 아직도 노트북 가운데에는 RAM을 정말 최소한으로 달아놓는 경우도 있으며, 사무용 컴퓨터에는 RAM 용량을 크게 하지 않는다. 또한, RAM이 늘어난 만큼 각종 프로그램들이 요구하는 RAM도 덩달아 상승해서 결국 남는 RAM이 그리 많지 않다. 그리고 일반적으로 컴퓨터로 한 가지 작업만 하는 것이 아니라 기타 여러 작업을 같이 하기 때문에 RAM을 적게 소모하는 것이 당연히 좋다고 볼 수 있다. 게다가 RAM 사용 최적화가 되어 있지 않다. 안 보는 탭을 RAM에서 내리는 등의 최적화 작업이 없이 무조건 다 올려놓는다. 한 개의 프로세스에 탭이 여러개 달려 있다가 1개만 남는 경우 등 메모리 반환 도중에 프로세스 완전 종료로 말미암은 반환이 아니면 효율이 매우 떨어진다. 리소스가 보통 빵빵한 데스크탑이면 이게 큰 문제가 아닐 수도 있다. 하지만 노트북 상황은 좀 다르다. 배터리가 그야말로 줄줄 새어나가며, 그 배터리 오래간다는 맥북류도 사용시간이 절반 이하로 깎여나갈 정도다. 때문에 맥북 관련 커뮤니티에서는 크롬을 고깝게 보는 실정.

메모리 누수가 없다지만, 그 메모리 누수를 고려하더라도 파이어폭스와는 비교할 수 없을 정도로 많은 메모리 사용량을 보여준다. 특히나 탭을 수십 개 이상 열어놓고 쓰는 사용자의 경우, 8 GB 이상의 메모리로도 메모리 부족으로 웹페이지 로딩에 실패한다는 메시지를 종종 볼 정도. 대략 파이어폭스의 서너 배 이상 먹는다. 크롬 1 버전에서는 실제로 파이어폭스보다 메모리 사용량이 적었고, 이 때문에 가볍다는 이야기가 많이 나왔으나 현재는 '아주 무거운 브라우저 가운데 하나'로 불러도 손색이 없다. 그래서 쾌적하게 사용하려면 따로 메모리 최적화 프로그램을 실행해야 한다. 빠르고 안전하다고 했지, 가볍다고 한 적은 없다.

이것은 탭마다 독립된 프로세스를 이용하는 크롬의 특징 때문이다.[22] 기존에는 하나의 프로세스로 모든 탭을 관리했는데, 수많은 탭 가운데 하나에만 에러가 나도 브라우저 전체가 꺼지는 단점이 있었다. 크롬은 각 탭마다 독립된 프로세스를 이용하여 메모리는 많이 먹지만, 탭 하나에 에러가 발생해도 해당 탭만 꺼지는 식으로 안정성을 확보하였다.[23] 다만 탭별로(정확히는 도메인별이다. 현재는 하나의 탭 안에서 iframe으로 다른 사이트를 띄워도 또 다른 프로세스가 뜨는 기능이 구현되어 있다) 개별 프로세스를 두는 방식의 진정한 장점은 보안성에 있다. 이런 장점에도 메모리를 많이 먹는 사실은 달라지지 않기에 창을 많이 띄우고 사용하는 넷북 등을 쓰는 저사양 유저는 파이어폭스에 램캐시 설정을 하여 쓰거나 IE 11나 엣지를 쓰는 것이 좋다.

결국, 구글도 이 문제를 인정하여, 45버전부터 본격적으로 시작해서 다이어트를 하고 있다. 그러나 여러차례 개선에도 여전히 사용량이 많은 것 또한 인정해서, 55 버전부터 추가적인 최적화를 하고 있다. 특히 리소스 점유율의 주범이자 보안에도 취약한 플래시 플레이어를 써야 하는 때에만 불러오도록 바꾸면서 큰 효과를 본 듯.

현재는 이제 대체로 램을 적게 먹는 모습을 보인다. 여러 차례의 논란이 있었지만, 70버전 이후로 램 먹는 비율이 다른 브라우저랑 동등하게 맞춰지는 등 가장 좋은 브라우저라는 평도 있는 상황이다. 게다가 해당 브라우저의 가장 큰 문제점인 최적화도 해결 되어, 더 이상 따질 필요가 없어진 현 시점으로 "램만 쳐먹는 뚱뚱한 브라우저"라고 불린 불명예는 어느 정도 씻어낸지 오래다. 물론 첫 인상이 심어 둔 램 소모량이 너무 강렬했던 탓에, 전에 크롬을 사용했던 사람들의 망령에서 완전히 벗어나진 못했다.

최근에는 오히려, 파이어폭스가 크롬보다 메모리를 많이 먹는다는 반대의 결과를 보여주는 조사 결과도 있다. 이제 크롬이, 메모리를 유독 많이 먹는 것은 옛말이 되었다. 사실 파이어폭스가 요새 램 돼지 다 된 게 크다

파일:CC-white.svg 이 문서의 내용 중 전체 또는 일부는
문서의 r670 판{{{#!wiki style="display: inline; display: none;"
, 번 문단}}}에서 가져왔습니다. 이전 역사 보러 가기
파일:CC-white.svg 이 문서의 내용 중 전체 또는 일부는 다른 문서에서 가져왔습니다.
[ 펼치기 · 접기 ]
문서의 r670 판{{{#!wiki style="display: inline; display: none;"
, 번 문단}}} (이전 역사)
문서의 r 판{{{#!wiki style="display: inline; display: none;"
, 번 문단}}} (이전 역사)

문서의 r 판{{{#!wiki style="display: inline; display: none;"
, 번 문단}}} (이전 역사)

문서의 r 판{{{#!wiki style="display: inline; display: none;"
, 번 문단}}} (이전 역사)

문서의 r 판{{{#!wiki style="display: inline; display: none;"
, 번 문단}}} (이전 역사)

문서의 r 판{{{#!wiki style="display: inline; display: none;"
, 번 문단}}} (이전 역사)

문서의 r 판{{{#!wiki style="display: inline; display: none;"
, 번 문단}}} (이전 역사)

문서의 r 판{{{#!wiki style="display: inline; display: none;"
, 번 문단}}} (이전 역사)

문서의 r 판{{{#!wiki style="display: inline; display: none;"
, 번 문단}}} (이전 역사)

문서의 r 판{{{#!wiki style="display: inline; display: none;"
, 번 문단}}} (이전 역사)

문서의 r 판{{{#!wiki style="display: inline; display: none;"
, 번 문단}}} (이전 역사)

문서의 r 판{{{#!wiki style="display: inline; display: none;"
, 번 문단}}} (이전 역사)

문서의 r 판{{{#!wiki style="display: inline; display: none;"
, 번 문단}}} (이전 역사)

문서의 r 판{{{#!wiki style="display: inline; display: none;"
, 번 문단}}} (이전 역사)

문서의 r 판{{{#!wiki style="display: inline; display: none;"
, 번 문단}}} (이전 역사)

문서의 r 판{{{#!wiki style="display: inline; display: none;"
, 번 문단}}} (이전 역사)

문서의 r 판{{{#!wiki style="display: inline; display: none;"
, 번 문단}}} (이전 역사)

문서의 r 판{{{#!wiki style="display: inline; display: none;"
, 번 문단}}} (이전 역사)

문서의 r 판{{{#!wiki style="display: inline; display: none;"
, 번 문단}}} (이전 역사)

문서의 r 판{{{#!wiki style="display: inline; display: none;"
, 번 문단}}} (이전 역사)

문서의 r 판{{{#!wiki style="display: inline; display: none;"
, 번 문단}}} (이전 역사)

문서의 r 판{{{#!wiki style="display: inline; display: none;"
, 번 문단}}} (이전 역사)

문서의 r 판{{{#!wiki style="display: inline; display: none;"
, 번 문단}}} (이전 역사)

문서의 r 판{{{#!wiki style="display: inline; display: none;"
, 번 문단}}} (이전 역사)

문서의 r 판{{{#!wiki style="display: inline; display: none;"
, 번 문단}}} (이전 역사)

문서의 r 판{{{#!wiki style="display: inline; display: none;"
, 번 문단}}} (이전 역사)

문서의 r 판{{{#!wiki style="display: inline; display: none;"
, 번 문단}}} (이전 역사)

문서의 r 판{{{#!wiki style="display: inline; display: none;"
, 번 문단}}} (이전 역사)

문서의 r 판{{{#!wiki style="display: inline; display: none;"
, 번 문단}}} (이전 역사)

문서의 r 판{{{#!wiki style="display: inline; display: none;"
, 번 문단}}} (이전 역사)

문서의 r 판{{{#!wiki style="display: inline; display: none;"
, 번 문단}}} (이전 역사)

문서의 r 판{{{#!wiki style="display: inline; display: none;"
, 번 문단}}} (이전 역사)

문서의 r 판{{{#!wiki style="display: inline; display: none;"
, 번 문단}}} (이전 역사)

문서의 r 판{{{#!wiki style="display: inline; display: none;"
, 번 문단}}} (이전 역사)

문서의 r 판{{{#!wiki style="display: inline; display: none;"
, 번 문단}}} (이전 역사)

문서의 r 판{{{#!wiki style="display: inline; display: none;"
, 번 문단}}} (이전 역사)

문서의 r 판{{{#!wiki style="display: inline; display: none;"
, 번 문단}}} (이전 역사)

문서의 r 판{{{#!wiki style="display: inline; display: none;"
, 번 문단}}} (이전 역사)

문서의 r 판{{{#!wiki style="display: inline; display: none;"
, 번 문단}}} (이전 역사)

문서의 r 판{{{#!wiki style="display: inline; display: none;"
, 번 문단}}} (이전 역사)

문서의 r 판{{{#!wiki style="display: inline; display: none;"
, 번 문단}}} (이전 역사)

문서의 r 판{{{#!wiki style="display: inline; display: none;"
, 번 문단}}} (이전 역사)

문서의 r 판{{{#!wiki style="display: inline; display: none;"
, 번 문단}}} (이전 역사)

문서의 r 판{{{#!wiki style="display: inline; display: none;"
, 번 문단}}} (이전 역사)

문서의 r 판{{{#!wiki style="display: inline; display: none;"
, 번 문단}}} (이전 역사)

문서의 r 판{{{#!wiki style="display: inline; display: none;"
, 번 문단}}} (이전 역사)

문서의 r 판{{{#!wiki style="display: inline; display: none;"
, 번 문단}}} (이전 역사)

문서의 r 판{{{#!wiki style="display: inline; display: none;"
, 번 문단}}} (이전 역사)

문서의 r 판{{{#!wiki style="display: inline; display: none;"
, 번 문단}}} (이전 역사)

문서의 r 판{{{#!wiki style="display: inline; display: none;"
, 번 문단}}} (이전 역사)




[1] 초록색으로 노이즈 끼듯이 발생하거나, 반쯤 깨진화면으로 나오고 다른 반쪽은 특정 영역만 반복 재생되는 현상이 주로 발생한다.[2] 특히 30프레임에서 60프레임으로 전환될 때, 또는 그 반대일 때 거의 100% 확률로 발생한다.[3] 크롬을 초기화하거나 프로그램 및 레지스트리 등 수동 삭제, 그리고 재설치해도 해결이 안된다.[4] 문제는 더블 클릭에 번역을 누르거나 손님 모드로는 자동번역이 뜬다.[5] 크롬만의 특징은 아니고, 다른 브라우저에도 모두 있는 기능이다.[해석] 이러한 버그가 튀어나왔을 때 수정 안하고 그대로 썼을 경우 이 같은 문장이 나오게 된다.[6] 링크 삭제됨[7] 스피디(speedy)라고 읽는다.[예시] 모니터 1은 Main 모니터이며 High DPI 모니터이다. 윈도우 10 권고사항에 따라 scale이 200%로 맞춰져 있다. 모니터 2는 Sub 모니터이며 일단 DPI 모니터이다. 윈도 10 권고사항에 따라 Scale이 100%이다. 이때, 2번 모니터에 크롬을 띄우면, Scale이 200%가 적용되어서 메뉴바를 포함한 크롬의 모든 내장 기능들이 다 200%로 확대되어 나온다.[8] 특히 새 탭으로 링크를 열 때 원래 페이지는 입력이 안 된다. 갤럭시 S5LG G5에서 확인.[9] 다만 영어와 특수문자는 정상적으로 입력이 된다. 참고로 천지인 자판 기준으로 한글 자판 내에 포함되어 있는 .,?! 특수문자는 처음에 입력했을 때 나오질 않다가 다른 글자를 누르면 나오라는 글자는 나오질 않고 처음에 입력한 그 특수문자가 나온다. 그리고 숫자 자판의 특수문자 .,-/의 경우는 처음에 눌렀을 때 안 뜨다가 숫자를 하나 누를 때 처음에 입력한 특수문자와 숫자가 같이 뜬다.[10] 북마크의 경우는 '설정'에 들어가서 '개인정보' 카테고리를 눌러 '추천 검색 및 추천 URL' 체크를 해제하면 북마크가 정상적으로 나온다.[11] 일본쪽 웹 사이트를 돌아다녀보면 잘 알 것이다. 특히 일본에서 사용하는 Shift_JIS 인코딩은 특성상 타 인코딩과의 충돌이 자주 발생한다. 한국이나 중국어권에도 이런 웹사이트가 더러 보인다.[12] Nvidia의 맥스웰 일부 칩셋과 파스칼, AMD의 폴라리스 칩셋 등이 VP9 하드웨어 디코딩을 지원한다.[출처2] 유독 크롬(계열)만 유튜브 끊길 때 - h264ify[13] 애초에 1440p/2160p 60 옵션들 자체가 VP9 서비스 다음에 생긴 VP9 전용 기능들이다.[14] 좀 부족하지만 H.265와 경쟁하는 코덱이다. 앞 세대인 H.264보다는 당연히 좋다. 따지고 보면 H.265는 물론 H.264도 처음 나온 당시에 하드웨어와 웹 브라우저로는 같은 문제가 있었다고 할 수 있다. 그 때는 유투브 VP9 영상 같이 최신 코덱을 적용한 서비스가 별로 없어서 겪을 일이 없었을 뿐.[15] VP9의 장점으로는, 압축 알고리즘의 개선을 통한 인공 영상(게임 영상, 애니메이션)의 화질 개선이 큰 편이다. VP9 코덱은 H.265처럼 동일한 대역폭에서 H.264 대비 PSNR 기준으로 35%의 화질 향상과 동일 해상도에서 H.264 대비 50%의 비트레이트를 절약할 수 있다. 유튜브는 비트레이트를 짜게 주기 때문에 H.264보다 VP9가 화질적인 이점은 크다. 물론 1080p 및 1080p 60까지는 유튜브가 대역폭을 낮게 할당하고 퀀타이저 방식이 아닌 ABR 방식으로 할당하기에 H.264나 VP9나 인공 영상에서 똑같이 화질이 좋지 못하지만, 1440p 및 1440p 60(VP9 단독 옵션)과 2160p 및 2160p 60(VP9 단독 옵션)부터는 퀀타이저 방식으로 대역폭을 할당하기에 여기부터는 인공 영상에서 VP9가 H.264 대비 월등한 화질 향상이 있다.[16] 이게 되야만 1080P이상을 재생할 수 있고, 60 프레임으로 볼 수 있다.[17] 정확히 몇 버전부터 지원하기 시작한 건지는 확인 바람[18] 당연히 낮을 수록 좋다[출처1] [추천] 유튜브 음질 - 크롬(또는 파폭)을 써야 되는 또한가지 이유[19] ISP의 DNS 서버를 사용하지 않으면 해결된다.[20] 위 짤에 들어간 브라우저들은 순서대로 파이어폭스, 사파리, 오페라, 엣지이다. IE는 졸지에 잉여가 되었다.[21] 엣지도 초기에는 메모리를 많이 소비하였지만, 현재는 지속적인 개선 덕분에 소비량이 다른 브라우저들과 비슷하다.[22] 사실 이는 IE 11도 마찬가지이므로 크롬만의 문제라고는 할 수 없다. 실제로 IE 11도 탭을 여러 개 띄우면 메모리 점유율이 매우 높아진다. 하지만 그렇다 하더라도 크롬은 같은 조건에서 메모리 점유율이 IE 11보다 훨씬 더 높다.[23] 물론 크롬이라도 핵심 프로세스에 오류가 발생하면 브라우저 전체가 꺼진다. 이는 기술적으로 해결할 수 없다.

관련 문서