Comments 9
Извиняюсь за оффтоп, но может стоит бороться с причиной, а не следствием?
Вместо того чтобы максимально облегчать страницу, фронтенд сейчас готов запаковать в билд весь репозиторий npm...
Что мне толку от вашей "обратной визуальной связи"? Мне контент нужен!))
Может не совсем правильно уловил мысль, вы имеете в виду, что не нужно ждать чего-либо, а нужен контент сразу и немедленно?
Ну я думаю в случаях, где есть таблицы/графики, аналитика данных, где нужно запрашивать огромные количества данных этого не избежать))
Может не совсем правильно уловил мысль, вы имеете в виду, что не нужно ждать чего-либо, а нужен контент сразу и немедленно?
Ну да. Не знаю как сейчас, но ещё пару лет назад очень актуальны были требования от гугловского Page Speed. Там, емнип, было что около максимум полутора секунд на рендеринг первого экрана. Типа как пользователь не любит ждать, и если он якобы прождёт больше полутора секунд и не дождётся контента - он покинет страницу)) Вопрос, конечно, дискуссионный. Но доля здравого смысла в этом есть.
А что до "где нужно запрашивать огромные количества данных" - ну это тогда вопросы к архитектуре. Запросить один массив данных - не самая ресурсоёмкая задача. Поясню - "чистые данные" (условный json) - весят совсем не много, в отличие от медиаконтента. Допускаю, что в каких-то проектах надо крутить прям огромные массивы данных, но тогда возникает логичный вопрос - какого лешего вы собрались делать это на клиенте? Вы же представляете себе зоопарк нынешних девайсов? И что обрабатывать такие объёмы данных придётся на условном смартфоне 7-летней давности...
Можно представить совсем уж специфическую ситуацию - у нас тяжеленное служебное приложение исключительно под десктопы. Но тогда я думаю пользователи этого приложения не облезнут и подождать десяток секунд (ну я же жду когда какой-нибудь raw-конвертер минуту стартует) без отрисовки этих скелетонов))
В целом, это конечно полезная практика. Равно как и семантичный код, "юзабилити", "аксессабилити" и т.п. Вопрос лишь в целесообразности. Стоит ли этот "доступный интерфейс" потраченных ресурсов на его разработку?
Да, я понял посыл, и в принципе согласен, что зачастую нужно работать над архитектурой и качеством приложения, а не пытаться это скрыть за анимашками и крутилками))
Но, в жизни не всегда всё бывает так гладко увы, как бы не хотелось переделать всё по нормальному. Ну, и в целом, идея была такой, что б для использования данного скелетона потратить минимум усилий, не переписывать существенно код или компоненты. А так, навесил пару классов и всё, оно работает себе.
Не, вопросов нет - статья ваша безусловно полезна. Может даже и мне когда пригодится))
И даже без препроцессоров (уж очень "фреймворщики" их любят) - респект.
Но вот моментик смутил:
.sm-loading .sm-item-primary - слишком общий селектор, кмк. надо будет очень внимательно отсматривать код, чтобы в блок .sm-loading не пролезли не нужные в нём .sm-item-primary
Скелетон на мой взгляд это не про долгое отображение контента, а про получение контента с сервера. Бэкенд не любой запрос может обработать быстро. Представить тот же ютуб, на странице допустим 12 видео, по каждому должны прийти метаданные (обложка, длина, название, канал и т.п.). Пока они не пришли, показывать нечего и тут 3 варианта - не показывать ничего, показывать спиннер или показывать скелетон.
Отдаваться контент может долго по разным причинам, например, пиковая нагрузка на сервис, плохой инет у пользователя, кривой бэкенд (вот с ним да, надо бороться :) ).
Пользуюсь такой штукой skeletonreact.com, результат очень крутой, на входе твоя svg, на выходе svg с анимацией. Есть под популярные фреймворки. Скопировал svg и вставил куда надо, никаких зависимостей. Преимущество svg в том, что оптимизация анимаций в браузере под капотом, в отличии от css анимаций. Размещать можно хоть 1000 анимированных элементов на странице, она не будет подвисать.
сокращая воспринимаемое время загрузки и смягчая потенциальное разочарование
Не согласен. Вот я жду что там будет что-то важное для меня (сообщение, емейл, заказ). Вижу скелетон с кучей строчек, предвкушаю. А потом там пусто или меньше чем нужно. И я очень разочарован!
А было бы обычное "загрузка" я бы меньше ожидал и у меня не было бы чувства, что мне почти дали желаемое (с точки зрения моего мозга скелетон это "почти контент", в то время как спиннер отдельная сущность), а потом забрали.
Крч когда скелетон имеет сценарий, что он превратится в пустоту или значительно меньшее количество реальных данных, то он может быть достаточно бесячим. Если силуэт соответствует по объёму тому что появится потом, либо появится даже больше, то норм.
Skeleton Mammoth — или как я решал проблему переиспользуемых скелетон лоадеров