Юрий

ibd копировал с источника при выключенном MySQL? В конфиге старого MySQL был включен innodb-file-per-table?
Если ты их копировал с включенным MySQL не используя xtrabackup - тогда с очень большой вероятностью ты не заведешь БД. Можно попробовать создавать пустые таблицы с такими же параметрами, как на источнике, затем выключать MySQL, подсовывать туда ibd и т.д.
Если в конфиге старого MySQL не был включен innodb-file-per-table - тогда все твои данные остались вообще в корне БД в ibdata1.

Единого совета тут дать нельзя.
Есть нечто общее для облегчения страданий.
1. (Тут я советую вообще всем направо и налево) Поставить nginx на отдачу статических файлов (не забыв включить сжатие), разгрузив апач. Этим немного снизится нагрузка при отдаче многочисленных JS и CSS-файлов. Т.е. общее самочувствие немного улучшится.
2. Включить slow-log в MySQL, чтобы увидеть медленно выполняющиеся запросы и запросы, которые не используют индексы. Люди часто забывают про составные индексы и в результате SELECT на пару полей, который должен в результате вернуть два значения, лопатит всю таблицу в несколько сотен тысяч записей.
3. Профилирование PHP. Поставить для PHP xdebug или XHProf. На примере xdebug - включил модуль, рестартнул/релоаднул апач, походил по самым тормозным ссылкам (или подождал несколько секунд, пока пользователи по ним походят), закомментил модуль, опять релоаднул апач, чтобы вернуть в нормальное состояние. Ну а затем QCacheGrind в руки, открываем самые жирные файлы дампов и смотрим, куда тратится время при выполнении...

Я тут не сильный специалист в плане кода, но...
При выполнении update_color перед запросом в БД (или после) заставить пользователя зарелоадить страницу (это если некритично, что долго), либо Javascipt-ом менять в браузере нужный блок в CSS.

Pending - это ожидание. Если у курильщика Chrome - тогда он ограничен 6 одновременными соединениями к одному ресурсу. Ты установил коннект, получил страницу и браузер начинает подгружать статику. И судя по браузеру "некурильщика" - у тебя там мелкие картинки, и на каждый файл надо установить соединение. С ограничением в 6 соединений, если у тебя сверху заливается нечто тормозящее - остальные будут курить до освобождения очереди.

Включаю телепатический шлем...

Как один из вариантов - объединить мелкие картинки в спрайты и грузить их одним коннектом, отображая с помощью CSS нужные участки в нужных местах. (Google PageSpeed тебе то же самое подскажет)
Второй, как полумера - использовать кеш браузеров клиента, чтобы не грузить картинки каждый раз с сервера. Но в первый раз все равно придется загрузить их со страницы в любом случае.
Далее, судя по всему у тебя либо подрезана скорость на доступ к веб-серверу, либо сервер откровенно тормозит. Картинку размером в 80КБ грузить секунду - это долго.
Рискну предположить, что у тебя в качестве веб-сервера стоит апач. В таком случае рекомендую увести его например на 127.0.0.1:80, а перед ним на этом же сервере на внешний интерфейс воткнуть nginx с простым конфигом:
(Естественно, путь до проекта и внешний IP-адрес подставить свои)

server {
  listen 192.168.0.1:80;
  server_name my-super-puper-project;
  
  location ~ ^.+\.(jpg|png) {
    root /home/www/your-project-name;
    expires 1d;
  }
  location / {
    proxy_pass http://127.0.0.1:80;
  }
}

В этом случае картинки (jpg|png) будет отдавать легковесный nginx без участия apache, что значительно разгрузит твой сервер, а на apache будет уходить все остальное (в т.ч. и ЧПУ-ссылки). Если у тебя css и js также отдаются прямо с диска, а не генерятся на каждый запрос динамически, как сумасшедшие - можно их включить в конфиг к картинкам.
Если с сетью порядок - браузер станет получать статические файлы гораздо быстрее, а значит время Pending тоже уменьшится, что благоприятно скажется на быстродействии.