Oronro

Эта «оптимизация» больше зависит от того, как эти данные будут обрабатываться и использоваться.

Первый вариант имеет право на жизнь, поскольку он позволяет в потоке «кусками» передавать строки таблицы (структура данных и предложенная оптимизация больше похожа на описание таблицы), более того, позволяет пропускать значения конкретных «столбцов» считая что обработчик на автомате подставит туда `null` значения — данных то нет.

Второй вполне логичная оптимизация, однако потоком такую «таблицу» уже не передать, поскольку структура не предусматривает это by design и `null` значения уже не пропустить, иначе собьется порядок следования значений «стоблцов».

Итого: it depends. Необходимость этой «оптимизации» зависит не от экономии, а от способа обработки данных.

P.S. Если нужно получить более компактное представление JSON данных, при этом не пугает binary-формат и не хочется связываться с gzip — можно попробовать UBJSON — при полной совместимости размер обычно меньше процентов на 20-40, особенно при малом количестве ascii-строк и обилии unicode и числовых значений.

А согласно какому закону, данные параметры должны быть съаггрегированы в массив? Данное поведение — исключительно удел PHP и/или библиотек, занимающейся обработкой url-параметров, не более чем.

Под линукс есть замечательная штука
swik.net/netem/
Можно эмулировать потери пакетов, задержки, ширину полосы и прочее. Профиль применения более широк, конечно, но для решения задачи тоже подойдет. Например, посмотреть на поведение при работе в 3G сетях.