BeArty

14ка - топ на сегодня, разрешение экрана приложенное к 16" macbook 2019, разница неощутима (там что то около 20px разница всего).
Больше всего стоит переплатить именно на екран, а мощности наверное хватит и Air.

Пункты, которые есть в разных ответах с конца 2020. У меня макбук с стратра их продажи. У жены air на минималках.
1) Air m1 справится.
2) Если брать air m1, то самую дешевую комплектацию (8,7) / 8 / (256/512). Разница между 8 и 16 оперативы конечно есть, но не настолько существенна. Я бы даже посоветовал б.у. брать, перед всем кипишем родственникам взяли минимальный air за 70К рублей. см следующий пункт.
3) Как только вы выбираете полноценный процессор 88, 16 и 512 памяти - разница в стоимости между m1 macbook pro практически нивелируется. И у вас встанет вопрос, а что вам действительно захочется купить? я взял macbook mq pro 13". Но сейчас они ушли из продажи, нов сегда можно найти новые или мало б.у.
4) 14" я не рассматриваю. На свой я переехал с 15 дюймового до 2015 года поколения. И я до сих пор работаю с внешним монитором. Поэтому на 14" я не смотрю, и следующий в планах было брать именно 16" M1 pro.

Для начала объявите для всех о каком объеме данных идет речь?

Если это 100 значений для построения графика и страница не догружается, то нужно смотреть что с сервером, может ответ долгий или на сервере к примеру каждое значение чтобы получить проходит миллион переборок в цикле и каждый проход обращается с запросом к БД.

Если это десятки, сотни тысяч значений, то нужно посмотреть через что вы пытаетесь их отобразить, если это JS библиотека малоизвестная, то возможно в ней проблема, может она тупит при построении, если это какой нибудь highcharts, то нужно смотреть опять же на стороне отдачи данных.

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

Большой объем можно разбить на более мелкие, ограничив к примеру датами, или усреднение показателей, тогда вам не придется гонять тонны данных от сервера к браузеру. Так же передавайте только необходимые данные, к примеру если для графика вам нужна дата и показатель, то отдавайте на сервере в JSON именно эти данные, не нужно к каждому показателю прилагать другие данные (заголовок, описание, дата создания, дата обновления, дата модерирования, всевозможные данные флагов и т.д.). Так вы можете сэкономить трафик, а это все время.

Как ранее писали, профилируйте. Смотрите кто тратит время, и от этого отталкивайтесь.

Профилируйте запросы к БД. Найдите узкое место. Устраните или копайте дальше.
Запросы к БД "напрямую" (без django) выполняются так же медленно? Если вы строите графики на фронте, и валится "вывод", то скорее всего узкое место в используемой библиотеке. Причем она по сути обертка для JS. Профилируйте работу javascript. Благо Chrome умеет это все в dev панели. Отлично показывает "затыки" в JS. Отделите ужа от ежа и ищите.

Где сложность?
интернет->server->коммутатор->wifi royter
--------------------------------------> PC1
--------------------------------------> PC2
--------------------------------------> PC3
--------------------------------------> PC4
--------------------------------------> PC5
В сервер вставить еще одну сетевуху, это не дорого и особых скилов не требует

Докупить в сервер еще одну сетевую карту.

"Роутер" подключить к серверу в режиме моста.

Модем подключить к серверу.

Офисную локалку-туда же.

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

Почитать "Компьютерные Сети" Танненбаума, чтобы не бегать в магазин за TCP-пакетами.

Собственно поборол! :)
Идем в биосе в раздел Boot, потом включаем Launch CSM, затем переходим в раздел Security и отключаем параметр Secure Boot Control.
Осталось засетапить убунту, рядом с Win7, но хочу ее на SSD залить. Разумеется кроме папки /home