Есть ли способ узнать что-либо об аппаратных ресурсах "платформы" для доступа к веб-странице?

Я хотел бы узнать о ресурсах браузера с веб-страницы или, по крайней мере, приблизительную оценку.

Даже если вы обнаружите наличие в браузере современных технологий (например, csstransforms3d, csstransitions, requestAnimationFrame) с помощью инструмента, такого как Modernizr, вы не можете быть уверены, следует ли активировать некоторую производительность (например, фантастическая 3D-анимация) или чтобы избежать этого.

Я спрашиваю, потому что у меня (много) опыта с ситуациями, когда браузер является современным (последний Chrome или Firefox, поддерживающий все классные технологии), но OS CPU, GPU и доступная память просто катастрофический (32-битная Windows XP со встроенным графическим процессором), и поэтому решение, основанное исключительно на обнаруженных крышках браузеров, не является хорошим.

Ответ 1

В общем, доступная (для веб-страниц) информация о пользовательской системе очень ограничена.

Я помню обсуждение добавления одного такого API к веб-платформе (navigator.hardwareConcurrency - количество доступных ядер), где противники Особенность объяснила причины, против которых, в частности:

Количество ядер, доступных вашему приложению, зависит от другой рабочей нагрузки, а не только от доступного оборудования. Он не является постоянным, и пользователь может не захотеть, чтобы ваше приложение использовало все (или любую фиксированную часть, которые вы выбрали) из доступных аппаратных ресурсов;
Помогает "fingerprinting" клиенту.
Тоже ориентируется на специфику сегодняшнего дня. Веб предназначен для работы на многих устройствах, некоторые из которых даже не существуют сегодня.

Эти аргументы также работают для других API-интерфейсов для запроса конкретных аппаратных ресурсов. Что конкретно вы хотели бы проверить, чтобы узнать, может ли пользовательская система позволить себе "фантазийную 3D-анимацию"?

Как пользователь, я бы предпочел, чтобы вы не использовали дополнительные ресурсы (например, фантазийную 3D-анимацию), если это не обязательно для основной функции вашего сайта/приложения. Мне грустно, что мне приходится покупать новый ноутбук каждые несколько лет, чтобы иметь возможность продолжить мой текущий рабочий процесс, не работая очень медленно из-за нехватки ресурсов HW.

Итак, вот что вы можете сделать:

Предоставьте резервную ссылку для пользователей, у которых возникают проблемы с "полной" версией сайта.
- Если это достаточно важно для вас, вы можете сначала запустить короткие тесты, чтобы проверить производительность и вернуться к менее ресурсоемкой версии сайта, если вы подозреваете, что система не хватает ресурсов.
Вы можете настроить таргетинг на конкретные высокопроизводительные платформы, проверив ОС, размер экрана и т.д.
- В этой статье упоминается этот метод на мобильных устройствах: http://blog.scottlogic.com/2014/12/12/html5-android-optimisation.html
WebGL предоставляет некоторую информацию о рендерере через webgl.getParameter(). См. Эту страницу, например: http://analyticalgraphicsinc.github.io/webglreport/

Ответ 2

В то время как Nickolay дал очень хорошее и обширное объяснение, я хотел бы предложить одно очень простое, но, возможно, эффективное решение - вы могли бы попытаться измерить, сколько времени потребуется для загрузки страницы, и решить, следует ли идти с ресурсом, головоломки или нет (Gmail делает что-то похожее - если загрузка продолжится слишком долго, появится предложение перейти на "базовую HTML-версию" ).

Идея заключается в том, что для медленных компьютеров загрузка любой страницы, независимо от содержимого, должна быть в среднем намного медленнее, чем на современных компьютерах. Получение времени, необходимого для загрузки страницы должно быть простым, но есть несколько замечаний:

Вам нужно немного поэкспериментировать, чтобы определить, где поставить "слишком медленный" порог.
Вам нужно иметь в виду, что медленные соединения могут привести к медленной загрузке страницы, но это, вероятно, повлияет на очень небольшое количество случаев (использование DOM, готовое вместо события загрузки, также может помочь здесь).
Кроме того, в первый раз, когда пользователь загружает ваш сайт, вероятно, будет намного медленнее из-за кэширования. Одним из простых решений для этого является сохранение вашего результата в cookie или локальном хранилище и учет времени загрузки только при первом посещении пользователя.
Не забывайте всегда, независимо от того, какой механизм обнаружения вы использовали и насколько он точным, разрешите пользователю выбирать между обычной, ресурсоемкой и более быстрой, "уродливой" версией - некоторые люди предпочитают более эффективные эффекты, даже если это означает, что веб-сайт будет медленнее, в то время как другие значения скорости и привязанности больше.