Речь шла о том, что чтобы не бороться с фреймворками, а использовать их, нужно всего-лишь соблюдать правила семантики (это ещё и в других аспектах пользу принесёт). Например, ссылки делать при помощи тега <a>, а для кнопок использовать <button> (а вот "поставил href='#'" - это не нормальное решение). И вот вас уже нисколько не касается написал кто-то в исходниках Бутстрапа странные правила или нет.
Это азбука веб-разработки, которую надо знать, на что вам тут в комментариях четыре человека пытаются указать.
Сами по себе NPM и Yarn занимают какие-то десятки мегабайт. Кэши у них тоже примерно одинаково работают. Ну а уж на то, какого размера у вас буду зависимости, пакетный менджер не влияет вовсе.
На реализацию всех описанных сценариев в сумме нужны пара часов. И вы получите максимально релевантные для себя данные. "Статистика и тесты общие" они потому и общие, что для каждого конкретного проекта пользы не несут. В любом случае, если говорить о нормальном сервере с нормальной схемой - это от одной до десяти секунд примерно займёт, далеко не три минуты.
Это никакого отношения не имеет к Laravel. Зависит от того а) какой конкретно запрос вы будете делать, б) какая структура у таблицы и какие в ней индексы, в) как настроена СУБД, г) какая именно СУБД используется, д) какое железо на сервере, е) и ещё куча других факторов.
Сразу говорю, что отвечать на эти вопросы не нужно, никто всё равно не сможет вам гарантировать какое-то время исполнения. Нужно просто написать код, запустить его и замерить, тогда вы получите точный ответ.
Но в случае сферического коня в вакууме обновить миллион записей - это не так уж и сложно, поэтому должно быть быстро. Но на всякий случай именно на этот кусок кода я бы поставил мьютекс (или блокировал таблицу средствами СУБД), чтобы второй процесс ждал разблокировки, без этого схема не будет надёжной.
А можно и вовсе использовать не статусы, а куда-то сохранять только id последней полученной записи, а следующий запрос делать от него, это будет ещё быстрее.
