Столкнулся с дизайн-системой, где у всех компонентов отрисованы состояния «скелет» — это типа как выглядит элемент, пока он не загрузился. Дизайнеры вообще говорили «скелетон», но скелетон — это такой бобслей для одиночек, а skeleton — это скелет. С этим состоянием есть проблема, сейчас объясню.
Пока экран приложения загружается, вместо индикаторов загрузки хорошо показывать скелет экрана. Тогда вместо того, чтобы привлекать внимание к тормозам, мы создаём у пользователя впечатление, что экран почти загрузился. Секундные задержки перестают ощущаться, человек успевает сориентироваться на экране.
Так что же не так с состоянием компонента «скелет»? То, что скелет — это состояние экрана целиком, а не отдельного компонента. (Если уж на то пошло, у компонента может быть состояние «кость», а не «скелет».)
Во-первых, рисование отдельных скелетных состояний компонентов провоцирует дизайнеров на рисование излишне детализированных скелетов экранов. Вот Вконтакте например:
Зачем столько мусора? Чтобы показать, что экран ещё грузится, достаточно такого:
Да и ещё спокойнее можно.
Во-вторых, во время загрузки экрана он обычно не знает, какие именно компоненты на нём будут, чем они будут наполнены, какого они будут размера. То есть даже непонятно, какие именно компоненты в этом состоянии «скелет» туда ставить, приходится выдумывать. В то же время, если какие-то элементы на экране нужны независимо от подгружаемых данных, скажем, кнопки навигации, то их стоит сразу показывать в нормальном виде, безо всяких скелетов.
В-третьих, даже если представить, что сам набор элементов известен сразу, а подгружается только их наполнение, то получается довольно неприятный эффект, когда во время загрузки на экране в случайные моменты появляются разные блоки, постоянно что-то прыгает, отталкивает то, что ниже. То есть даже в этом случае лучше нарисовать весь экран в скелетном состоянии, а когда загрузилось достаточно данных для его стабильного построения — тогда показать всё на своих местах.
Я работал в разных компаниях над супернагруженными приложениями с огромным набором данных и с маленькими приложениями с небольшим набором данных. И почти в каждом проекте наступал момент, когда дизайнер приходил ко мне, или к начальнику выше с предложением сделать «скелетон» у какого-то блока, а ещё лучше у всех блоков на всех страницах потому, что что-то стало медленно загружаться. Главный бекэндер понимающе кивал. Это происходило независимо от размеров проекта, данных, числа пользователей.
Я говорил, что в этом нет никакой необходимости, и нам нужно думать и прилагать усилия к тому, как поставлять данные и страницы быстро, а не как пытаться замаскировать эту проблему. Дизайнер, бекэндер и девопс были против и говорили, что это, если не невозможно, то точно сложно и займёт много времени. Я приводил примеры, как можно настроить кэш веб-сервера, и его инвалидировать, как предугадывать, какие данные потребуются в первую очередь, или даже хранить все данные в оперативной памяти в тех проектах, где данных мало. Ещё можно страницы на сервере предформировать. Ну ещё можно сервера поближе переместить к пользователям. Бекэндер был против, но технический директор был за потому, что это увеличивало возможную выдерживаемую нагрузку.
И каждый раз оказывалось, что за месяц или меньше и вправду мы настраивали всё так, что страницы загружались молниеносно и «скелетоны» оказывались ненужными. Однажды в одном большом проекте контрагент решил в понедельник с утра залить к нам невероятный объём своих данных. Клиенты почувствовали это и некоторые даже пожаловались. Страницы в это утро загружались не молниеносно, а за полсекунды. Жалко, но «скелетоны» всё ещё были не нужны с такой скоростью загрузки.
Сергей Копылов,
Это не совсем верно для массовых сайтов с широкой аудиторией.
Вы не можете решить проблему последней мили. Ваш пользователь может нуждаться в вашем сайте и не быть в зоне действия быстрого интернета. Особенно это актуально для мобильных устройств, удалённых регионов и, особенно, в последнее время. По-моему, скелетон не должен быть решением скорости «по умолчанию», но иметь это состояние важно.
Вопрос: а «скелетон» вообще зачем? Что он должен пользователю показать?
Что вот в этих местах будет контент?
Полагаю, юзер и сам об этом немного догадывается.
Что «у нас что-то грузится?»
Для этого не нужны все представленные рамки, ну грузится и грузится, все равно пока не загрузится, ничего работать не будет.
Что контент будет вот такого формата? Ну окей, а зачем мне это знание.
Вдобавок, когда загрузится, еще и формата будет другого, чего я нового узнал, непонятно.
Что мы модные и умеем рисовать скелетоны?
Рад за авторов, молодцы, нужное дело делают, высокий приоритет.
Внезапно: для отрисовки этого «скелета» тоже нужно передать какие-то байтики его дизайна (а с современным блотваром как бы не мегабайтики) с сервера до клиента, включая пресловутую «последнюю милю». Тем самым скелет только утяжеляет и тормозит приложение. Время, потраченное на загрузку и отрисовку скелета лучше потратить на загрузку и отрисовку реальных элементов. А вместе скелета — показывать старый добрый спиннер, который занимает полкилобайта.
Вот не надо этого. Куда ни зайдешь — везде мерцающие скелеты. Типа работает, ага, а на самом деле сплошная фикция. Лучше бы сделали так, чтобы интерфейс прогружался сразу.
Если уж совсем не можешь не тащить сразу с сервера отрендеренную страницу, и все эти мегабайты скриптов и правда нужны, покажи скромно логотип в центре окна, пока оно грузится. И сделай так, чтобы на нормальном канале грузилось не больше секунды, а не как ВК. Там основная проблема мусора вовсе не в «скелете». До момента первой отрисовки *осмысленного* контента он загружает 10 мегабайт (!), а вся страница весит больше 60.