У нас в TeamHood есть wiki. Там собралась коллекция рекомендаций, в том числе, по улучшению производительности тяжелого фронтенда на vue.js. Улучшать производительность понадобилось, потому что в силу специфики наши основные экраны не имеют пагинации. Есть клиенты, у которых на одной kanban/gantt доске больше тысячи вот таких вот карточек, все это должно работать без лагов.
В статье разобрано несколько редко упоминаемых техник из нашей wiki, которые помогут сократить излишний рендеринг компонентов и улучшить производительность.
Примеры статьи собраны в отдельном репозитории. Это vue2 приложение, хотя все проверено и продолжает быть актуальным для vue3. Пока что не вся экосистема vue3 production-ready. В vuex4 утекает память, исследовать соответствующие оптимизации там пока бессмысленно (что обнадеживает, затраты памяти там в разы меньше чем в vue2+vuex3). Примеры написаны на минимальном простейшем javascript, было искушение воткнуть vue-class-component, typescript, typed-vuex и остальную кухню реального проекта, но удержался.
1. (Deep) Object Watchers
Правило - не использовать deep модификатор, использовать watch только для примитивных типов. Расмотрим пример. Некий массив items приходит с сервера, сохраняется в vuex store, отрисовывается, возле каждого item есть чекбокс. Свойство isChecked относится к интерфейсу, хранится отдельно от item, однако есть getter, который собирает их вместе:
export const state = () => ({
items: [{ id: 1, name: 'First' }, { id: 2, name: 'Second' }],
checkedItemIds: [1, 2]
})
export const getters = {
extendedItems (state) {
return state.items.map(item => ({
...item,
isChecked: state.checkedItemIds.includes(item.id)
}))
}
}
Допустим, items могут быть отсортированы, будем сохранять порядок. Что-то вроде:
export default class ItemList extends Vue {
computed: {
extendedItems () { return this.$store.getters.extendedItems },
itemIds () { return this.extendedItems.map(item => item.id) }
},
watch: {
itemIds () {
console.log('Saving new items order...', this.itemIds)
}
}
}
Здесь переключение чекбокса у любого item вызывается излишнее срабатывание сохранение порядка. Конструирование новых объектов - настолько естественный процесс, что даже в этом тривиальном примере мы делаем это дважды. Изменение checkedItemIds вызвает пересоздание массива extendedItems (и пересоздание каждого элемента этого массива), затем идет пересоздание объекта itemIds. Это может казаться контра-интуитивным, ведь создается массив, состоящий из тех же самых элементов в том же самом порядке. Однако, это природа javascript, [1,2,3] != [1,2,3]. Демо здесь: example1.
Решение - полный отказ от использования watcher для объектов и массивов. Для каждого сложного watcher создается отдельный computed примитивного типа. Например, если требуется отслеживать свойства {id, title, userId}
в массиве items, можно отслеживать строку:
computed: {
itemsTrigger () {
return JSON.stringify(items.map(item => ({
id: item.id,
title: item.title,
userId: item.userId
})))
}
},
watch: {
itemsTrigger () {
// Здесь не нужен JSON.parse - дешевле пользоваться исходным this.items;
}
}
Очевидно, чем точнее условие для срабатывания watcher, тем лучше, тем точнее он срабатывает.
Объектный watcher - плохо, deep watcher - еще хуже. Использование deep в коде - частый признак неграмотности разработчика. Типа я не понимаю что делает этот код, какими объектами он оперирует, но что-то иногда не срабатывает, навешу-ка я deep - о вроде работает.
Это что-то уровня.. (был у меня и такой проект).. в компоненте не срабатывала реактивность, и вместо того, чтобы найти ошибку, был повешен $emit('reinit'), по которому родительский компонент убивал данный и создавал его заново в $nextTick. Все это забавно мигало.
2. Ограничение реактивности через Object.freeze
Использование Object.freeze на проекте TeamHood сократило потребление памяти в 2 раза. Однако оно больше относится к моему второму основному проекту, StarBright, где используется nuxt и серверный рендеринг. Nuxt подразумевает, что некоторые запросы будут отрабатываться на сервере заранее. Ответы сохраняются в vuex store (и потом используются на клиенте). Таким образом, всю логику работы с запросами и кешированием данных удобнее держать в vuex. Компонент делает this.$store.dispatch('fetch', …), а vuex отдает кеш или делает запрос.
Следовательно, в vuex может содержаться большой объем данных. Например, пользователь вводил адрес, autocomplete загрузил массив городов, который был закеширован в store с целью избежать повторной загрузки. Данные статичны, однако vue по умолчанию делает реактивным каждое свойство каждого объекта (рекурсивно). Во многих случаях это приводит к высокому расходу памяти, и лучше пожертвовать реактивностью отдельных свойств.
// Вместо
state: () => ({
items: []
}),
mutations: {
setItems (state, items) {
state.items = items
},
markItemCompleted (state, itemId) {
const item = state.items.find(item => item.id === itemId)
if (item) {
item.completed = true
}
}
}
// Делаем
state: () => ({
items: []
}),
mutations: {
setItems (state, items) {
state.items = items.map(item => Object.freeze(item))
},
markItemCompleted (state, itemId) {
const itemIndex = state.items.find(item => item.id === itemId)
if (itemIndex !== -1) {
// Не получится делать item.completed = true (объект заморожен), нужно пересоздать весь объект;
const newItem = {
...state.items[itemIndex],
completed: true
}
state.items.splice(itemIndex, 1, Object.freeze(newItem))
}
}
}
Пример здесь: example2. Замечу, что замерять расход памяти нужно на build-версии (не в development).
3. Функциональные геттеры
Иногда это пропускают в документации. Функциональные геттеры не кешируются. Вот это будет делать items.find для каждого компонента:
// Vuex:
getters: {
itemById: (state) => (itemId) => state.items.find(item => item.id === itemId)
}
...
// Some <Item :item-id="itemId" /> component:
computed: {
item () { return this.$store.getters.itemById(this.itemId) }
}
Вот это построит объект itemsByIds при первом обращении и закеширует результат:
getters: {
itemByIds: (state) => state.items.reduce((out, item) => {
out[item.id] = item
return out
}, {})
}
// Some <Item :item-id="itemId" /> component:
computed: {
item () { return this.$store.getters.itemsByIds[this.itemId] }
}
Пример здесь: example3.
4. Грамотное распределение на компоненты
Компоненты - ключевая часть экосистемы vue. Понимание жизненного цикла и критериев обновления (shouldComponentUpdate) необходимо для строительства эффективного приложения. Первое знакомство с компонентами проходит на интуитивно-логическом уровне: есть список каких-то однотипных контейнеров, тогда наверное для контейнера лучше сделать отдельный компонент.
Однако, кроме смыслового значения, компоненты - это мощный механизм, дающий контроль над гранулярностью обновлений, это штука, напрямую влияющая на производительность. Рассмотрим такой (ужасный) код:
// Store:
export const getters = {
extendedItems (state) {
return state.items.map(item => ({
...item,
isChecked: state.checkedItemIds.includes(item.id)
}))
},
extendedItemsByIds (state, getters) {
return getters.extendedItems.reduce((out, extendedItem) => {
out[extendedItem.id] = extendedItem
return out
}, {})
}
}
// App.vue:
<ItemById for="id in $store.state.ids" :key="id" :item-id="id />
// Item.vue:
<template>
<div>{{ item.title }}</div>
</template>
<script>
export default {
props: ['itemId'],
computed: {
item () { return this.$store.getters.extendedItemsByIds[this.itemId] }
},
updated () {
console.count('Item updated')
}
}
</script>
Пример работы здесь: example4p1. Обновление любого свойства одного item вызывает обновление всех компонентов <Item>. Причина в том, что технически <Item> ссылается на объект extendedItemsByIds, который пересоздается заново при изменении любого свойства любого item.
Каждый vue компонент - это функция, которая отдает virtual DOM и кеширует его (memoization). Входные аргументы функции - зависимости - отлеживаются на этапе dry run и состоят из ссылок на переменные в props и глобальные объекты типа $store. Если аргумент - поэлементно равный предыдущему новый объект, кеширование не срабатывает.
Изначальная структура данных в store неудачная. Мы начали применять normalizr подход, но не доделали. Удобнее хранить сортировку в отдельном массиве ids. Так же, вместо копирования всех свойств объекта в getter, лучше просто хранить ссылку на весь объект. Например, так:
// Store:
export const state = () => ({
ids: [],
itemsByIds: {},
checkedIds: []
})
export const getters = {
extendedItems (state, getters) {
return state.ids.map(id => ({
id,
item: state.itemsByIds[id],
isChecked: state.checkedIds.includes(id)
}))
}
}
export const mutations = {
renameItem (state, { id, title }) {
const item = state.itemsByIds[id]
if (item) {
state.itemsByIds[id] = Object.freeze({
...item,
title
})
}
},
setCheckedItemById (state, { id, isChecked }) {
const index = state.checkedIds.indexOf(id)
if (isChecked && index === -1) {
state.checkedIds.push(id)
} else if (!isChecked && index !== -1) {
state.checkedIds.splice(index, 1)
}
}
}
// Item.vue:
computed: {
item () {
return this.$store.state.itemsByIds[this.itemId]
},
isChecked () {
return this.$store.state.checkedIds.includes(this.itemId)
}
}
Заметим, что мутация renameItem не перестраивает state.itemsByIds, а обновляет только один элемент оттуда. Поэтому rename работает правильно: example4p2. Однако isChecked все равно ссылается на весь state.checkedIds (ищет там значение), поэтому чекбокс по-прежнему вызывает полный ререндеринг всех <Item>.
Эта ошибка уйдет, если в каждый <Item> гранулярно передать только его параметры:
<Item
v-for="extendedItem in extendedItems"
:key="extendedItem.id"
:item="extendedItem.item"
:is-checked="extendedItem.isChecked"
/>
Пример здесь: example4p3.
5. Применение IntersectionObserver
Отрисовка большого DOM-дерева тормозит сама по себе. Мы применяем несколько техник для оптимизации. Например, на gantt схемах размеры и положения блоков заранее расчитаны, поэтому известно, что попадает в viewport. Невидимые элементы не отрисовываются. В других случаях размеры заранее неизвестны, тогда можно применить этот простой прием с intersection observer. В vuetify есть v-intersect директива, которая работает из коробки, однако она создает отдельный IntersectionObserver на каждый свой биндинг, поэтому не подходит для случая, когда объектов много.
Вот пример, который будем оптимизировать: example5. Там 100 элементов (на экране помещается 10), в каждом мигает тяжелая картинка, замеряется задержка между реальным миганием и расчетным. Создадим один экземпляр IntersectionObserver и пробросим его через директиву во все узлы, которые он будет отслеживать.Все, что нужно от директивы - зарегистрироваться в переданном IntersectionObserver:
export default {
inserted (el, { value: observer }) {
if (observer instanceof IntersectionObserver) {
observer.observe(el)
}
el._intersectionObserver = observer
},
update (el, { value: newObserver }) {
const oldObserver = el._intersectionObserver
const isOldObserver = oldObserver instanceof IntersectionObserver
const isNewObserver = newObserver instanceof IntersectionObserver
if (!isOldObserver && !isNewObserver) || (isOldObserver && (oldObserver === newObserver)) {
return false
}
if (isOldObserver) {
oldObserver.unobserve(el)
el._intersectionObserver = undefined
}
if (isNewObserver) {
newObserver.observe(el)
el._intersectionObserver = newObserver
}
},
unbind (el) {
if (el._intersectionObserver instanceof IntersectionObserver) {
el._intersectionObserver.unobserve(el)
}
el._intersectionObserver = undefined
}
}
Теперь известно, какие элементы списка не видны, вопрос, как их облегчать. Можно, например, проставить какие-то vue переменные, на основе которых тяжелый компонент будет заменяться на легкую заглушку. Однако важно понимать, что сложный компонент сложно отрисовывать. При быстром скролинге страница затупит из-за большого количества инициализаций и деинициализаций. Практика показывает, что хорошо работает скрытие на уровне css:
<template>
<div
v-for="i in 100"
:key="i"
v-node-intersect="intersectionObserver"
class="rr-intersectionable"
>
<Heavy />
</div>
</template>
<script>
export default {
data () {
return {
intersectionObserver: new IntersectionObserver(this.handleIntersections)
}
},
methods: {
handleIntersections (entries) {
entries.forEach((entry) => {
const className = 'rr-intersectionable--invisible'
if (entry.isIntersecting) {
entry.target.classList.remove(className)
} else {
entry.target.classList.add(className)
}
})
}
}
}
</script>
<style>
.rr-intersectionable--invisible .rr-heavy-part
display: none
</style>