Нет, не всегда 😉 Бэкенд я, кстати, пока не оптимизировал, только фронтенд.
Кое-где я убрал ненужные запросы и лишние перерисовки React. Выключил во многих местах компоненты, которые обрабатывались даже тогда, когда не показывались, некоторые из них довольно тяжёлые.
Сделал обработку CORS-запросов прямо на уровне nginx. Из-за того, что сеть децентрализованная и клиент работает одновременно с разными серверами, у нас довольно много CORS-запросов. А Spring тупо обрабатывает их как обычный GET, тратя попусту кучу времени.
Уменьшил размер загрузочного бандла. Частично - просто убрав некоторые зависимости. (Спасибо open source, я могу просто скопировать одну функцию, и не тянуть всю библиотеку 😉) Частично - сделав ленивую загрузку компонент, которые не нужны прямо сразу. Код redux распилить сложнее, пока оставил как есть.
Вынес часть кода в worker-ы. Ты ж помнишь, что JavaScript однопоточный? Но если есть что-то, что выполняется долго, но с DOM напрямую не связано, можно запустить worker, который будет работать в параллельном потоке. Например, работу с WebSockets. Заодно и этот код уйдёт из основного загрузочного бандла.
И, наконец, самое неожиданное. Есть у меня код, который проверяет ответы от нод на предмет соблюдения протокола. Ведь клиент не может доверять нодам. Это делается через библиотеку ajv. Ей даются описания структур, и по ним она сверяет наличие нужных полей, типы данных, удаляет лишнее и т.п. Так вот, оказалось, что это занимает дикое количество времени. Сначала я вынес всё в worker. Неожиданно, время работы основного потока сократилось на 80%, а остальное время он сидел и ждал результатов работы потока с ajv 😲 А поток с ajv занимался не столько проверкой структур, сколько начальной загрузкой и компиляцией схем 😲 И тогда я нашёл, как компилировать схемы заранее 😉
Comments (6)
слушай, загрузка с нуля правда быстрая. кешинг? это же всегда кешинг 😁
Отлично!
огонь, просто летает, по сравнению с тем что было
Нет, не всегда 😉 Бэкенд я, кстати, пока не оптимизировал, только фронтенд.
вау, крут совсем
Ты крут