Иван Корюков

Корзину надо хранить в БД, привязывать к пользователю или к идетификатор сессии пользователя, если он не авторизован.
В момент авторизации прописываем id пользователя в корзину текущей сессии.

Обязательно предусмотреть крон-команду, котрая будет удалять слишком старые корзины не привязанные к пользователям.

Часто корзина это не только набор товаров, но и какие-то более общие параметры, например промокод, поэтому лучше корзину делать из нескольких таблиц, например baskets и basket_items

https://placehold.it/150x150

А как вы измеряли скорость ответа?
Если вы не написали бенчмарк, который на сотне тысяч итераций доказывает что один метод быстрее другого, то разница во времени ответа может быть случайностью.
Важен ещё способ получения времени ответа, ведь можно измерять как время обработки запроса сервером, так и полное время отправки и получения ответа.

Вообще чисто теоретически разница в скорости может происходить из того факта, что методом POST данные отправляются в другом виде, соответственно может быть затрачено разное время на формирование запроса, на отправку большего объёма данных и на чтение данных на сервере.
Ну например, данные закодированные в multipart/form-data однозначно по размеру больше чем в query string.

Но даже если допустить, что POST реально медленнее, то это не повод отказываться от него в пользу GET.
Это какая-то преждевременная оптимизация получается. Какая там разница? 10 миллисекунд какие-нибудь? Для вас это настолько критично? Никто и не заметит. Вот когда упрётесь в скорость ответа, и когда эта небольшая разница будет решающей, тогда можно будет задуматься.

Про важные данные - опасность есть ровно одна - те данные, которые указаны в query string вашего запроса, они попадут в историю браузера, в логи разных серверов, которые передают данные.
Например вы отправляете форму входа методом GET.
Ну и что что у пользователя в адресной строке мелькнёт его пароль - он же сам его и ввёл. А вот на сервере в логах apache или nginx появится строчка типа /login?user=vasya&pass=12345
Само по себе это не очень страшно - ну логи, чё мне с них, у меня вся БД с пользователями под рукой.
Но если кто-то найдёт уязвимость на вашем сайте и как-то прочитает логи, то будет плохо.

Веб-компоненты - обобщающее название нескольких технологий, позволяющих создавать собственные элементы с инкапсулированными структурой, стилями и поведением.
Т.е. вы создаёте один-два файла в какой-нибудь папочке, описываете в них разметку, стили и js-код и вызовом некоторых api-функций говорите браузеру - "вот мой собственный элемент с именем my-element, если встретишь тэг , то наполни его вот этим, стилизуй вот так и по событиям выполняй этот код".
Технологии, которые это позволяют постепенно появляются в браузерах, но как обычно не полностью и не везде. Нужны полифилы.

И да, веб-компонент мужского рода)

Mamp, xampp и прочие это не веб-серверы, а наборы программ с панелью управления. Все они содержат в себе веб-сервер Apache, СУБД MySQL и интерпретатор PHP.
Поэтому вообще не важно какую именно сборку вы выберете. На начальном этапе между ними нет никакой разницы - включил и работает. Дальше либо придётся копать глубже и вы полюбому будете пробовать разное и даже научитесь работать напрямую с программами. Либо глубже копать не придётся и тогда тем более не важно что вы поставите.

Чем вас не устраивает первый вариант и в чём плюсы второго?
Логика подсказывает, что дублировать пост для каждого юзера, который на него подписан это абсурд.
Хотите сказать, что если я делаю пост в группу в которой 100к подписчиков, то я сразу создаю 100к записей в базе?
Количество постов в таблице постов будет больше чем в первом варианте на несколько порядков и это только замедлит выборку.

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

select * from posts join subscribe sub on(...) where sub.user_id=123

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

Не парьтесь. Делайте так как считаете нужным, но знайте, что при росте количества пользователей вам придётся ещё разок всё переписать, а при выходе на мировой уровень, скорее всего у вас уже будет команда спецов, и вы ещё пару раз всё перепишете с нуля на других технологиях.

Важно понимать, что сначала отрабатывает PHP, который формирует и отдаёт html, а уже потом. Браузер, приняв этот html, рендерит его, ну и если у чего-то там display:none, то не показывает этого.
Вам надо сразу не генерировать этот div. Как это сделать зависит от того кода который у вас уже есть.

Если хотите много динамики на странице, то смотрите в сторону SPA (Single Page Application), т.к. jQuery лапша с ростом количества динамических частей на старнице начнёт запутываться.
Но это отнюдь не "не очень сложное", т.к. мир SPA фреймворков это наверное одна из самых быстро развивающихся областей программирования.