Хорошенько проанализируйте какие именно данные меняются и как часто.
Например иногда очень удачно получается так что в проекте основной объем данных на клиенте - значения справочников, т.е. фактически на клиентскую сторону от сервера нужно передавать только id записей в таблицах-справочниках, которые изменяются очень редко, точнее это не основной поток изменений.
А значит необходимо от сервера к клиенту пустить поток на синхронизацию таблиц-справочников (т.е. в вебсокет канале у вас будут сообщения вида add/remove/modify table_name id,value) и все объекты передавать в виде набора id (даже если это нормализованная табличка, описывающая граф, из тысяч строчек - будет не страшно, так как там будет много повторений и пустых ячеек).
Будьте осторожны, даже упакованный набор id, сериализованный в виде json - не эффективен (из-за наименований полей, либо их тоже надо кодировать) и возможно вам лучше использовать бинарный сериализатор структур, не передающий эти имена в принципе, таким является google protobuf для примера, поддержка кучи языков позволяет и в веб его использовать.
p.s. справочники можно первично на клиент передавать статичными файлами, если редко меняются, или последовательностью из лога их изменений (файл на дату в прошлом и несколько файлов с дампом истории изменений, как часто обновлять файлы - вопрос статистики). В этом случае файлы будут закешированы штатным кешем браузера.
Иначе вам придется хранить данные в отдельном хранилище браузера (само собой с версией, и запрашивать при подключении историю изменений на дату), это немного неудобно но дает больше контроля по управлению кешем.
Простой
