smilingcheater

Регулярка такая

\[(?<id>id(?<idNumber>.*?))\|(?<notify>@(?<name>.*?))\]

На выходе получаем такой результат по группам

Group `id` id296954377
Group `idNumber` 296954377
Group `notify` @wert43211
Group `name` wert43211

$re = '/\[(?<id>id(?<idNumber>.*?))\|(?<notify>@(?<name>.*?))\]/m';
$str = '[id296954377|@wert43211]';

preg_match_all($re, $str, $matches, PREG_SET_ORDER, 0);

// Print the entire match result
var_dump($matches);

1. node modules не надо иметь в репозитории. только package.json
2. github это не хостинг. Есть Github pages, но он не воспринимает ничего кроме статики package.json

350 мегабит по вайфаю - это уже очень хорошо. Чем больше между вами и точкой бетонных стен и соседских вайфаев, тем хуже ваш результат. Хотите скорости - тяните провод.

Во-первых, это не сложный вопрос, а простой.
Во-вторых, это не стандартный набор.
В-третьих, это не стили не цепляются, а просто ваши библиотеки не заиничены на новых записях которые отрисованы позже, асинхронно

Пользуйся редакторами, которые не херят файлы при выключении. Еще можешь попробовать в проводнике правый клик по файлу - восстановить предыдущие версии.

Учитывая ситуацию, усвой урок, делай бекапы, используй git и пиши разметку заново.

Условие цикла проверяется каждую итерацию. Следовательно, если там будет переменная со статическим значением - это будет слегка быстрее. Но такого рода оптимизация является едва ли не лишней. Уверен, у вас будут просадки более серьёзные.

Самые удобные и топовые вики ВСЕГДА идут там же, где размещен репозиторий. То есть, гитхаб \ гитлаб вики. Лично я всегда ожидаю увидеть вики по проекту там же, где и репо, и сильно расстраиваюсь, если ничего там не нахожу. Всякие левые сервисы проигрывают по причине заведомой неявности.

Любая.
В том числе и текущая.
Подвисает это проблема не CMS, а проблема ее грамотной настройки и тюнинга.
Ну и особой разницы нет - 100 у вас товаров или 100тыс товаров.

Количество товаров, тем более такое смешное, никаких таких особых требований к интернет-магазину не выдвигает.

Для современных СУБД - это смешное число.

Единственное, что будет критично:

1) Развитые механизмы фильтрации. Чтобы облегчить поиск по такому количеству для покупателя.
2) Какие-то автоматизированные процедуры загрузки, обновления данных о товарах (описаний, цен, фильтров).

Годится любой движок интернет-магазина. Кроме самых наипримитивнейших.

Дело не в движке - дело в умении ваших технических специалистов им пользоваться.
Скажем, автоматическое обновление данных наладить откуда-то - из файлов? Из 1С?

Упомянутая технология Woocomerce легко держит и 500 000 товаров.
Все дело в вашем умении ей пользоваться.

На любом другом движке - будет та же жопка.

Проблема тут не в движке.
Проблема в людях, кто его обслуживают.

Имхо, просто обратиться к компетентным людям и что они скажут то и ставить.
Для начала - обратиться к компетентным специалистам по Woocomerce.

В плане отдачи статики - врядли Ваш код хоть на php хоть на node сможет тягаться по скорости с Nginx, иначе Вы не задавали бы подобные вопросы. В любом случае стоит ставить nginx перед любым бэкендом, хоть php хоть node. Помимо раздачи статики еще получите и нормальную работу с tls и балансировку.
По динамике:
php - работает только в режиме 1 запрос = 1 процесс, соответственно процессов в памяти будет больше, а значит и больше памяти потребуется и больше процессорного времени будет уходить на switch-context. Так же и очередь ожидающих запросов будет больше ибо php работает синхронно, а это значит что при ожидании io (файлы/бд) Ваш процесс в idle. Самый быстрый вариант сейчас с php-fpm, который работает по протоколу fastcgi и держит пул предзапущенных потоков php. Так же возможна работа по http с apache, но этот вариант явно медленнее и тяжелее чем php-fpm.
node - может обрабатывать много запросов в 1 процессе засчет асинхронной модели выполнения, соответственно Вам может хватить небольшого количества процессов для очень большой нагрузки. Можно работать с nginx как по протоколу http (есть из коробки) так и fastcgi (при этом по прежнему имея 1 процесс)

Теперь по нагрузочному тестированию, нужно хорошо разбираться в обоих тестируемых технологиях, знать о возможных оптимизациях и как их обойти. И даже при всем этом Вы не получите адекватных результатов на синтетических примерах... Можно сравнить решение конкретной задачи, но для этого придется разработать решение на обоих технологиях, а оно Вам надо? БольшАя часть задержек в большинстве веб-сервисов падает на базу данных, которая особо не зависит от выбранного ЯП, хотя асинхронная модель тут предпочтительнее...
Так что пишите на чем умеете

Все фигня. Ускорить верстку можно на порядок, если не смотришь на экран после каждого изменения.

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

Microsoft Access

Всерьез задумался над тем, чем является таймер на духовке