Chrome ест гиг памяти

[Debugger]

С созданием сайтов я знаком слабо, но надо быстро и дешево склепать простой сервис.
На одной из страничек я предлагаю пользователю выбрать картинку, как только он выбирает - подгружают её на страничку (HTML5, без обращения к серверу). Картинка редактируется, и потом её надо отправить php-скрипту. Для этого я её исходную и отредактированную картинку кодирую в base64, записываю в скрытые textarea (в input'ы уже не помещается), и отправляю форму (POST-методом, естественно).
Всё окей, всё работает. Я продолжаю клепать сайт, потом возвращаюсь к этой страничке, отправляю картинку, и тут падает Apache. Смотрю логи - ничего интересного. Выключаю всё, что выключается, повторяю процедуру - всё работает. Начинаю потихоньку запускать разные программы и сервисы, и в какой-то момент скрипт начинает выполняться ~10 секунд вместо "моментально". Я заглядываю в диспетчер задач - и вижу, что Chrome при отправке формы ест ГИГАБАЙТ памяти. Картинки, которые я пытаюсь отправить, суммарно занимают в base64 ~4Мб.

Итак, вопросы:
Что я делаю не так?
Зачем Chrome столько ест?
Насколько неадекватно отправлять картинки в base64?

P.S. Да, на машине всего 2Гб.

[Qwertiy]

Зачем Chrome столько ест?

Профайлер Хрома в помощь

Насколько неадекватно отправлять картинки в base64?

Да как-то не слишком адекватно...

[Proxy]

записываю в скрытые textarea

Chrome при отправке формы ест ГИГАБАЙТ памяти

Полагаю, что textarea и не рассчитывался на такое использование (~4Мб текста).
Видимо проблема связана с тем, что полученный base64 текст не содержит разрывов и это каким-то образом приводит к проблемам с отрисовкой (и по-видимому даже для скрытых элементов отрисовка производится).
Иные варианты в голову не приходят.

И да, кажется уже где-то сталкивался с тормозами при отрисовке огромного абзаца. И тут, предполагаю, происходит следующее:
для textarea отрисовываются целиком абзацы (текстовые блоки), попадающие в область просмотра (непроверенная гипотеза). Если при текущем скролле большой неразрывный абзац (без пробелов, табуляции и разметки) попадает в видимую (ну или "видимую") пользователем область, то он отрисовывается полностью (ну и как часто бывает с обработкой текста, зависимость между объемом текста и потреблением ресурсов нелинейна, т.к. на 4Мб бинарных данных (пусть даже преобразованных в BASE64, это никак не облегчает отрисовку) хромиум всяко не рассчитывался).

Ну и ещё предполагаю такой вариант: скрытые поля не отрисовываются, но при простое начинается какая-нибудь отрисовка в кэш, чтобы ускорить отрисовку в том случае, если скрытое поле будет отображено в дальнейшем (полагаю на этом уровне браузер уже не видит отличий между элементом с "display:none" в css, input с параметром type="hidden" (который скорее-всего всё же совсем никогда не отрисовывается) или ещё как-то скрытым элементом).
Ну а вот использование "visibility:hidden" напротив явно приведёт к полной отрисовке текста, т.к. здесь это как минимум потребуется для оценки размеров элемента. Ну и гигантский 4MiB абзац вполне может привести к неприятностям.

PS. Даже если я ошибаюсь насчет отрисовки абзаца целиком, то тем не менее в textarea окажется одно огромное слово. И если даже абзацы не отрисовываются целиком, то слова наверняка не могут быть разбиты при отрисовке. Если даже просто 4MiB данных многократно копируются в памяти, то это уже затратно по времени. А если представить себе обработку растра, полученного из 4MiB текста, вместо ожидаемой обработки растра пофрагментно из слов по 60-70 символов, то явно почва для непредвиденных трудностей имеется.
PPS. Хотя наверняка все так делают и мои предположения относительно ограничении размера для устоявшейся практики беспочвенны (я с веб разработкой мало сталкиваюсь).

[Qwertiy]

Proxy, не думаю. Скорее там в редактировании память где-то течёт - надо скрипты править.