4X_Pro

Настройками кеша эту проблему точно не исправить. Тут может быть несколько причин:
1) если клиент и сервер — на разных машинах, то перегруженность сетевого соединения между ними (или еще какие-то проблемы с ним)
2) нехватка оперативной памяти
3) недостаточный объем thread stack, если запросы очень сложные
4) ошибки в файловой системе, в которой лежат файлы базы данных
Еще могу посоветовать сделать вот что: скачать скрипт mysqltuner и посмотреть его выдачу, иногда это позволяет гораздо быстрее понять проблему. Если клиент и сервер на одной машине, то можно попробовать переключиться с соединения по TCP/IP на Unix socket или наоборот.

Я бы сделал следующее:
1) картинка - обязательно progressive JPEG, а не обычный (и как следует оптимизировать)
2) CSS не во внешний файл, а прямо в код страницы в тег style
3) неблокирующая асинхронная загрузка всех JavaScript (но тут придется повозиться, вешая цепочку событий onload)
Посоветовать что-либо еще, не видя конкретного сайта, довольно сложно.

Это из-за так называемого strict mode, включающего ряд дополнительных проверок, в том числе невозможность записи строки в double. В консоли он по умолчанию включен, в PHP — выключен.
Чтобы его отключить, нужно сделать запрос
SET SESSION sql_mode = '';

Не очень понятна задача. Если нужно конкретно эту картинку загрузить, то можно открыть ее в каком-то графическом редакторе и сохранить заново (либо сконвертировать в PNG, а потом обратно в JPEG на своем компьютере), а потом загружать.
Если требуется убрать предупреждения при загрузке поврежденных картинок вообще, то нужно поставить @ перед imagecreatefromjpeg.

Кроме БД, проблемы с кодировкой могут быть в других местах.
Во-первых, на сервере. Если это Apache, то имеет смысл прописать что-то вроде AddDefaultCharset utf-8 в .htaccess
Во-вторых, проверить, не используется ли шрифт, не поддерживающий кириллицу.
В-третьих, попробовать прописать в начале скрипта ini_set('mbstring.internal_encoding','UTF-8'), чтобы не возникало проблем при обработке строк в самом PHP.

Скорее всего, у вас остаются невыбранные данные после выполненных запросов. Сделайте после всех SELECT-запросов mysqli_free_result($res).
Автоматически соединение может не закрываться, если PHP работает с использованием persistent_connections (а также, возможно, в режиме FastCGI, но точно не уверен, нужно документацию смотреть).

Зависит от того, возможен ли одновременный приход данных из разных источников (скажем, два пользоваеля сразу обратились к сайту). Если да, то лучше SQL, так как без него придется самостоятельно делать блокировку файла, чтобы не получилось так, что оба пользователя пишут одновременно. Но базы данных SQL вполне можно поместить и на SSD.
Вообще, информации, конечно, маловато, но так сходу могу предположить, что лучше всего на данном этапе вам подойдет SQLite.

Тут есть два варианта. Первый — пользователь заходит через IPv6, а скрипт пытается преобразовать его адрес с помощью ip2long, который корректно понимает только IPv4. Второй — пользователь заходит через proxy, который что-то передает в X-Forwarded-For, что некорректно преобразовывается в IP-адрес (например, передает не IP, а доменное имя).
Чтобы этого не было, нужно сохранять IP не как число, а как строку, причем сохранять туда и $_SERVER['REMOTE_ADDR'], и $_SERVER['HTTP_X_FORWARDED_FOR'] (тогда как многие скрипты при наличии второго REMOTE_ADDR просто отбрасывают).