rPman

Сервер который отдает картинки перегружен (упирается в лимиты), когда вы его долбите сразу большим количеством мелких файлов.

Отличной практикой в этом случае является собрать иконки в одно большое изображение (это еще и по размерам будет эффективнее) а при выводе каждую обрезать, указывая прямо в атрибутах или стилях позицию.

В итоге у вас будет только один запрос на сервер вместо 1000, что само по себе на порядок быстрее, и иконки будут выведены только после полной их загрузки (в случае с jpeg кстати есть бонус - будут выводиться сначала пониженное разрешение потом повыше).

Наверняка - корявые плагины в браузере у заказчика, к сожалению это наша реальность и с этим ничего не поделаешь. Попробуйте для отладки сохранить на сервере содержимое document.innerHTML и сравните с вашим.

где-нибудь сверху поставьте <a href="#" id="xxx"> а в нужный момент перейдите location.href = "#xxx";

Положите свое видео в виде файла на свой сервер и заверните его в тег video

Форматы и кодеки видеофайла смотреть тут:
https://ru.wikipedia.org/wiki/HTML5_video
https://developer.mozilla.org/ru/docs/Web/HTML/Под...

p.s. легальность использования того или иного кодека, то еще развлечение, но в вашем случае скорее всего теоретическое

в 99% случаев авторизация нужна на всех страницах, после авторизации пользователь хочет видеть ту же самую страницу.

javascript форма авторизации получается очень простой, ей почти все равно, одна страница авторизации или несколько.

http авторизации потребует передачу текущей страницы в качестве одного из параметров в форму авторизации, с последующим переходом по этой ссылке, как недостаток - теряются введенные данные на этой странице, если они там были (например форма заказа, которую пользователь заполнил до авторизации), т.е. для ее сохранения вам опять понадобится что то изобретать, а javascript авторизация может не перезагружать страницу со всеми вытекающими бонусами.

Не буду повторять вышесказанные очевидности… но порекомендую мыслить в следующем направлении:
1. разделить контент (статьи) на две части короткое емкое описание и полный текст
2. ограничить доступ к полным статьям поисковым роботам (кому от этого плохо? так ли вам нужны поисковики на весь контент?)
3. ограничить доступ к полным статьям на пользователей (куки)
3.a) изучать рефереры и юзерагент (в общем случае можно даже выявить не совсем опытных сканеров, последовательно выкачивающих ресурсы, вычисляя распределение во времени и т.п. не тривиально но реально)
3.b) ip, подсети (под суетитесь и соберите информацию о доступных хостерах и их подсетях), анонимных прокси, i2p и tor роутерах, информация обо всем этом общедоступна.
p.s. интересно, можно ли у антивирусных компаний запрашивать информацию о текущих сетях ботнетов?
Ограничение — частота возможных запросов, при превышении отлуп… при достаточно большом объеме данных время, которое потребуется атакующему собрать все данные станет неадекватно большим даже при наличии ресурсов вида маленький ботнет
4. ссылка на полную статью размещается в короткой статье, статичной делать ее нельзя — т.е. должна формироваться каждый раз новая, легко вычисляемой тоже (детские глупости в виде последовательно растущего номера тут не подходят), воспользоваться всем что доступно в аресенале для защиты от ботов, полиморфный javascript, привязка скрипта к багам популярных браузеров (защита от интерпретаторов), капчи как графические так и логические загадки

Если после этого вы не распугаете всех своих посетителей, возможно вы продержитесь пол года-год :)

Я просто грущу… для этой задачи требуют фреймворк???
Создаете make файл коммандный (bash/cmd/ets..) вида:

php my_page_template.php > my_site_paje.html
....

А внутри файлов обычный php… он именно для этого и создавался.

ВСЕ, внутри php можете подключать любой из миллиона cms (в разумных пределах конечно же), фреймоврков и т.п. а можете просто include ограничиться

У вас только один сайт так мешает? Напишите расширение, greasemonkey (или для хрома нативно) невероятно простые, ваш случай укладывается в одну строчку (в зависимости от желания… можно сразу пароль закодировать в плагин, можно интегрироваться с вашим автозаполняющим формы — и создать плагином фиктивное поле для пароля (пусть в него пароль вставляется менеджером паролей) а после плагин скриптом раскидывает его куда нужно.

Я работал с .net на с# компонент webbrowser (в windows текущая установленная версия IE) и успешно проверял его работоспособность на mono (используется библиотеки firefox).

Из явных проблем — неоднозначности в определении окончания загрузки страницы и некоторые особенности по выполнении своего javascript кода на странице — вместо вызова самого метода с большей совместимостью (если требуется вызывать методы из чужого не поддерживаемого кода) лучше вызывать этот метод через setTimeout(1).