Firefox를 더 느리게 만들기위한 궁극적 인 가이드 : 신화 속도를 높이세요
- 범주: Firefox
Firefox는 느린 브라우저가 아닙니다. 귀하의 경험은 다를 수 있지만 Firefox는 대부분의 웹 페이지와 사이트를 Google 크롬만큼 빠르게로드하고 있다고 생각합니다. 적어도 차이를 구분하기는 어렵습니다.
Google 크롬에서 브라우징 속도를 높일 수 있지만 Firefox 웹 브라우저와 비교할 때 사용 가능한 옵션은 상당히 제한적입니다.
웹 사이트가 브라우저에서 더 빨리로드되도록 Firefox를 구성 할 수 있습니다. 벤치 마크에만 나열된 개선 사항이 아니라 웹 브라우저에서 사이트를로드 할 때 눈에 띄는 실제 개선 사항에 대해 이야기하는 것이 아닙니다.
그러나 효과가 없거나 Firefox의 페이지 로딩 성능에 부정적인 영향을 미치는 조정이 있습니다. 이 기사는 그것에 관한 것입니다.
Google, Bing 또는 Startpage와 같은 검색 엔진에서 Firefox 속도를 높이는 방법을 검색 할 때 눈에 띄는 주요 문제 중 하나는 대부분의 가이드가 구식이라는 것입니다.
너 어떻게 알아? 더 이상 사용되지 않는 기본 설정을 참조하거나 변경된 값을 사용함을 인식합니다.
network.http.pipelining
파이프 라이닝 및 관련 기본 설정을 활성화하기 위해 제안 된 많은 가이드. 일반 및 프록시 연결에 대해 파이프 라이닝을 활성화하거나 최대 요청 수를 4 개에서 8 개로 늘릴 것을 제안 할 수 있습니다.
연구 결과 이 파이프 링은 브라우저의 페이지 로딩 시간에 영향을 미치지 않습니다. 적어도 현재 형식은 아닙니다.
연구원에 따르면, 대부분의 웹 사이트는 서로 다른 도메인에서 콘텐츠를로드하여 파이프 링의 효율성을 떨어 뜨리고 페이지의 병목 현상으로 인해 효율성도 제한되기 때문입니다.
따라서 엄청난 속도 향상을 기대하고 파이어 폭스에서 파이프 라이닝을 활성화하면 전혀 실망 스러울 것입니다.
설상가상으로, network.http.pipelining.maxrequests 매개 변수를 8로 수정하라는 제안은 최신 버전의 Firefox에서 32로 설정되어 있기 때문에 아무런 효과가 없습니다.
그런 다음 network.http.max-connections 매개 변수의 값을 64로 늘릴 것을 제안하는 사이트가 있습니다. 몇 년 전에는 작동했을 수도 있지만 매개 변수의 새 기본값이 256이므로 더 이상 작동하지 않습니다.
다음으로 많은 가이드에서 언급하는 network.http.max-connections-per-server가 있습니다. Firefox에서 network.http.max-persistent-connections-per-server를 관련 환경 설정으로 만드는 환경 설정이 Firefox에서 제거되었습니다.
browser.cache. *
따라서 하드 드라이브 캐시를 비활성화하고 캐시를 메모리로 이동하면 메모리가 디스크보다 빠르기 때문에 검색 속도가 빨라집니다.
반드시 그런 것은 아니다 . 우선, Firefox는 이미 기본적으로 두 캐시를 모두 사용하고 있습니다. 즉, 일부 캐시 된 항목은 이미 메모리에 있으므로 필요할 때 거기에서로드됩니다.
디스크 캐시를 비활성화하더라도 사용됩니다. 이것에 대한 단순하고 간단한 예는 Firefox의 메모리 캐시가 꽉 찼을 때입니다.
Firefox에서만 메모리 캐시를 사용하는 데 부정적인 영향이 있습니다. 일부 항목은 디스크에 캐시되지 않기 때문에 영구적이지 않습니다. 재시작 후 Firefox에서 웹 사이트의 페이지 로딩 시간이 늘어날 수 있습니다.
나는 그것이 Firefox에서 속도를 높이 지 않는다고 말하는 것이 아니라 매개 변수가 올바른 경우에만 가능합니다. 한 번의 브라우징 세션에서 사이트를 여러 번 방문하면 속도가 향상 될 수 있습니다. 예를 들어 Firefox가 느린 디스크에 저장되면 더 많고, 예를 들어 솔리드 스테이트 드라이브와 같은 빠른 드라이브에 저장되는 경우에는 더 이상 없습니다.
config.trim_on_minimize
Firefox를 최소화하면 RAM이 교체되어 시스템의 다른 프로그램 및 프로세스에서 RAM이 줄어들고 사용할 수 있습니다.
그 의미는 데이터가 당분간 디스크에 저장되어 Firefox가 복원 될 때 지연 될 수 있다는 것입니다.
Mozilla는 2008 년에 최소화-스왑 기능이 실제로 아무 일도하지 않는다는 것을 발견했습니다.
Windows의 주요 문제는 작업 관리자가 인터페이스에 있으며 대부분의 응용 프로그램에서 최소화 작업이 가시적 인 효과를 갖는다는 것입니다. 그러나 실제로는 아무 일도하지 않습니다. 응용 프로그램이 이제 교체 될 후보 라고만 말합니다 (Windows 95 시절에 유용 했음). 그러나 응용 프로그램이 메모리를 다시 터치하면 해당 메모리 부분이 다시 활성 상태로 표시되고 메모리 사용량이 다시 증가하는 것처럼 보입니다 (하지만 이는 착각입니다). 백그라운드에서 많은 작업을 수행하는 응용 프로그램은 다시 바로 되돌아가는 것처럼 보이지만 실제로는 실제로 변경된 것이 없습니다 (하드 디스크 표시등을보십시오. 깜박 거리지도 않았습니다!).
마무리 단어
200x로 가이드를 다시 작성한 저자는 당시 상황이 달랐기 때문에 여기에서 실제로 비난받을 필요가 없습니다. 여기서 가장 중요한 문제는 오늘날의 저자가 이러한 가이드를 다시 선택하고 있다는 것입니다.
검색 엔진은 오늘날 거의 사용되지 않는 경우가 아니더라도 검색 결과의 상단에 오래된 가이드를 유지하기 때문에 부분적으로 책임이 있습니다.
반면에 연구를하지 않고 이러한 선호도를 모방하는 오늘날의 저자는 대부분 그 책임이 있습니다. 이전 가이드와 그 안에 게시 된 제안을 사용하여 Firefox 속도를 높이는 방법에 대한 기사를 작성하는 것은 쉽습니다.