Comments 13
Придумывают загрузочные экраны вместо того, чтобы делать быстрые приложения. Такими темпами нужно будет делать загрузочный экран для загрузочного экрана!
Ребята подскажите пожалуйста, как запретить сайтам определять моё железо (материнку и т.п.) ? Может быть есть какое-нибудь дополнение для браузера?
Для начала давайте разберёмся как вообще сайт может определить материнку. У вас есть образец такого сайта или скрипта?
Фингерпринтинг. Модель материнской платы нет, а уникальные особенности железа да.
Фингерпринтинг в браузере обычно отслеживает не уникальные особенности железа (скрипт вряд ли до низкого уровня доберётся), а программную среду: браузер, операционную систему, системное время, часовой пояс и так далее. Но тут есть нюанс, что если какое-либо расширение пытается заблокировать фингерпринтинг по какому-либо параметру, то обнаружение этой блокировки — само по себе маркер пользователя, потому что такими расширениями пользуются единицы.
Огромное количество сайтов занимается определением железа посетителей - это всякие Avito, Ebay, Microsoft, Google, которые любят банить подозрительных пользователей. Ну вот например, при авторизации в свой аккаунт Гугол прислал мне предупреждение о подозрительном входе:
B85M-D3V - это модель материнки. Меня сильно удивляет, что туземцы с Хабра об этом не знают - я думал тут профессионалы веб-программирования...
Из-за токсичных аборигенов с Хабра у меня низкая карма, поэтому я могу отвечать только не чаще 1 раза в сутки...
Я хотел традиционно пошутить про то, что лучше бы сайты такими толстыми не делали.
Но статья на самом деле толковая и упоминает как про это, так и про то, что есть все же случаи, когда загрузка нужна.
Я бы добавил, что стоит разделять задачи на несколько основных категорий, условно, быстрые и медленные.
- Обычная загрузка сайта.
Тут как раз хорош совет в целом сделать его поменьше и пошустрее, но, очевидно, у сайта есть функции, меньше которых оптимизировать дорого.
В этом смысле индикатор загрузки / скелетон - лишь небольшой трюк + индикатор правильности работы сайта. Поэтому ему нет смысла быть детерменированным и стараться показать время.
- Специализированные задачи. Мы формируем важный годовой отчет, строим графики по аналитике за пол года, отправляем корабли на Марс или запускаем большую и красивую игру с 2 гб текстур.
Эту операцию нельзя оптимизировать с нашей точки зрения, пользователю остается только ждать.
В этом случае имеет смысл использовать детерменированные индикаторы.
Но так же важно в этом случае по возможности отделить эту функциональность от остальной страницы.
График грузится в рабочей области, таблица обновляет скелет таблицы - остальная часть сайта/приложения на самом деле может работать как обычно и быть отзывчивой.
То есть помимо загрузки нужно подумать и об архитектуре и абстрагировании этой медленной части.
Спасибо за комментарий и идеи.
Если честно, то о сайтах даже и не задумывался, в силу специфики своей работы)
Согласен с вами про разделение на загрузку данных и выполнение задач, но фокусировал внимание именно на загрузке, чтобы не перегрузить читателей. Лишь вскользь упомянув этот момент.
Про архитектуру — тут моё упущение, отдельное спасибо, что обратили на это внимание! Относительно недавно писал внутреннюю статью про скелетоны, где и раскрывал эту тему. Но постеснялся повторяться. Надо бы это исправить)
Это часто очень большая проблема при обсуждении приемов, паттернов и архитектур - слишком мало контекста.
Советы, полезные одним, могут быть вредными для других.
Простой пример - когда серверники рекламируют stateless организацию кода, функциональный подход, они прежде всего ориентируются на серверные же приложения, потому что это их типичные приложения.
И советы могут быть в корне неверными для statefull приложений, которыми, к примеру, являются игры. В них от состояния никуда не деться и главное, что нужно понимать - как его организовывать и не испытывать боли.
Разбираемся, зачем нужен и как выбрать оптимальный загрузочный экран для вашего веб-продукта