Возьмем картинку размером 1000×1000. Она одна в распакованном виде замет 4 мегабайта. А ведь она может быть на странице не одна. Возьмем jQuery (без плагинов), он только в ходе загрузки создаст кучу замыканий и массивов, которые займут память. А ведь люди еще и плагинов всяких наподключают, чтобы мало не показалось. Потом, в ходе парсинга HTML, надо выделять память под DOM. W3C каждый день без устали придумывает аттрибуты тегов и css-свойства, и под каждое нужно выделять память.
Также, в памяти могут храниться ресурсы предыдущей страницы для быстрого срабатывания кнопки «назад».
Явасрипт-код может сохранять данные в массивах/переменных в глобальной области видимости, и они не освободятся до закрытия или перезагрузки страницы.
Дальше. Если у вас в браузере не запрещен флеш, наверняка на стрнанице есть 1-2 баннера и может еще какие-нибудь невидимые flash-компоненты. Они требуют создания для них потоков и памяти для хранения ресурсов и всякого хлама.
Еще дальше. Наверняка на странице есть кнопки Like/+1, вход через соцсети и прочая нечисть. Они. как правило, создают отделбный ифрейм, и в особо запущенных случаях, грузят в него скрипты, jQuery с 10 плагинами и CSS. То есть каждая такая кнопка становится сопосставима по расходам ресурсов с обычной веб-страницей.
Идем дальше. Наверняка у автора есть расширения в Хроме? Каждое расширение имеет свой DOM и JS контекст, то есть соответствует открытой веб-странице. а может у автора фаерфокс с firebug? Тогаж память вообще будет уходить немеряно.
Идем еще дальше. Если а автора открыта вкладка с ютубом, наверняка и видеоролик закешировался в памяти для быстрого доступа.
Теперь посмотрим на разработчиков Chrome из компании Google. Устав бороться с кривыми и глючными библиотеками, они подошли к решению проблемы радикально — разнесли в отдельные процессы браузер, вкладки и плагины. Стоит ли говорить, что в плане производительности это отнюдь прироста не дает. Также. авторы Хрома не стесняются добавлять в него библиотеки типа ICU.dll весом в 11 мегабайт, исключительно для того, чтобы правильно сортировать какую-нибудь никому не нужную ханойскую письменность. Видимо, у сотрудников Гугла компьютеры с таким количеством памяти, что 11 мегабайт для
них ничего не говорят.
Кстати, в Хроме удобно смотреть сколько памяти онимает конкретная страница или расширение (Shift + Esc). Например, добавив на HTML-страничку тег SCRIPT, мы видим как потребление памяти подскакивает с 4 до 11 Мб (подгрузился хваленый v8).
А ведь все это, как вы догадываетесь, отнюдь не предел для современных школоразработчиков. Новые JS-фреймворки, новые HTML 5/CSS3 свойства и прочие радости еще ждут нас впереди.
А, если автор повелся на обещания маркетологов и купил 64-битный процессор, то программы начинают потреблять где-то раза в 2 больше памяти. То есть, покупая такой процессор, стоит сразу же закупать в 2 раза больше памяти, чем хватило бы на 32-битной системе.
