RidgeA

1. Кешировать можно все, что позволяет кешировать бизнес-логика. Мизерный прирост в 10-ти местах может дать суммарно лучше прирост, т.к. эти мизерные запросы не будут лишний раз насиловать базу и база сможет быстрее обслуживать запросы.
2. Можно кешировать страницы и http запросы на уровне веб-сервера, до php запрос не должен дойти вообще - это может дать прирость общей производительности.
3. Если это что-то вроде блога, где посты меняются не так часто, а то и вообще не меняются, можно основные странички сгенерировать в уже готовый html и отдавать их как статику через web-сервер. Менять эти странички на серваке в случае какого-либо изменения.

По сути, точно так же как и в обычной frontend разработке.
Эти файлы надо подключать в скрипте который подключается в index.html.
Не стоит использовать одновременно vuejs и jq, они по-разному работают с DOM и можно все поломать. Если есть необходимость во VueJS (как и Angular, React, etc) использовать jquery, то что-то пошло не так...

в package.json scripts -> test нужно прописать cli-команду для запуска тестов в выбранном фреймворке.
после этого можно запускать через `npm test`.
Как это сделать в jest надо читать документацию.

PS
`npm run test` === `npm run-script test` === `npm test` === `npm t` === `npm tst`
https://docs.npmjs.com/cli/test

Если в проводнике на файле нажать ctrl-c, то весь файл не копируется в буфер обмена, а только путь к нему (и, вроде, какая-то мета информация, что бы обозначить что это таки файл, а не просто строка с путем к файлу; представь, что кто-то скопирует в буфер обмена файл размером 10Гб, писать его в буфер обмена смысла нет в принципе), задача принимающего приложения обработать такую вставку корректно, если браузер этого не предоставляет, то ничего не получиться.

Если много посетителей на сайте, как будут выглядеть логи

Ровно так, как на программируешь.

будут логи для всех пользователей в перемешку?

В базовом варианте да.

Можно логи для каждого пользователя/запроса писать в отдельный файл (надо помнить, что делать много файлов в одной директории - идея плохая и чистить), можно в логах писать для какого пользователя/запроса/чтоугодно этот лог пишется что бы по этому признаку выбрать логи, как правильно подсказали через grep.
Можно прикрутить более продвинутые средства анализа логов как ELK-stack, если действительно есть необходимость.

Но базовый вариант с grep еще никого не подводил, если правильно писать логи.

Перед запуском сервиса вычитать пути и код из базы, и создать функции из этого кода. Потом зарегистрировать обработчики на пути, где в качестве обработчика повесить эту функцию.
Потом запустить сервис.

О том, что идея, мягко говоря, "так себе" я говорить не буду....

У меня на ноуте лицензионный ключ вшит в UEFI, скорее всего.
При подобной операции (при покупке ноута я SSD купил отдельно и поставил сразу) винда, скачанная с сайта ms подхватила лицензию автоматом.

1. Почему MySQL?, возможно MongoDB или Cassandra подойдут лучше.
2. Какого рода статистика нужна по этим данным?
3. ИМХО лучше не класть в базу по одной записи, а аккумулировать записи и писать в базу (вне зависимости от базы) пачками. Для аккумуляции подойдет какой-то брокер очередей (например RabbitMQ). К. т. очереди позволят сгладить пики нагрузки - в базу будет писаться более-менее равномерно, в пики - просто будет увеличиваться очередь.

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

Каждое свойство отдельной колонкой.
Это позволит выбрать только нужные свойства, если все не надо и сделать поиск по свойствам.

проверить заголовок hosts запроса и сопоставить с списком запрещенных

хранить цену в одной валюте, при запросах делать пересчет с помощью скриптов

https://www.elastic.co/guide/en/elasticsearch/refe...

https://www.elastic.co/guide/en/elasticsearch/refe...

https://www.elastic.co/guide/en/elasticsearch/refe...