From d214d9651feca9836fab1e6381ad4320e78a0c23 Mon Sep 17 00:00:00 2001 From: Carsten Date: Tue, 21 Jul 2015 01:01:50 +0200 Subject: [PATCH] =?UTF-8?q?=C2=B5Block=20->=20uBlock?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- ...-footprint:-what-happens-inside-uBlock-after-installation.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Memory-footprint:-what-happens-inside-uBlock-after-installation.md b/Memory-footprint:-what-happens-inside-uBlock-after-installation.md index da608ac..f9ff9be 100644 --- a/Memory-footprint:-what-happens-inside-uBlock-after-installation.md +++ b/Memory-footprint:-what-happens-inside-uBlock-after-installation.md @@ -18,7 +18,7 @@ - As opposed to an extension's own memory footprint, visible using Chromium's _"Task Manager"_, the contributed memory footprint to web pages cannot be easily seen by users - Though this measure is not readily visible, it's where you get the biggest bang for the buck with uBlock relative to ABP -- because uBlock **does not** inject thousands of CSS rules into pages and embedded frames (unlike ABP) -Once you have reached the point where there is a valid uBlock selfie, µBlock will run the most efficiently. +Once you have reached the point where there is a valid uBlock selfie, uBlock will run the most efficiently. The next time you launch uBlock and there is a valid selfie, the load time will be a fraction of the load time when no selfie is available [1], and uBlock's baseline memory footprint will be smaller than when uBlock launches without a selfie available.