Более интенсивный ресурс: скрипт Tampermonkey (для управления видео), работающий на ВСЕХ доменах - или только по 1 КБ доменам, каждый со своей записью @include?

Question

У меня быстрый вопрос - и я заранее прошу прощения, если ответ (или должен быть) очевиден ... вопрос может выдать мою основную [то есть, в основном несуществующую] беглость в коде.

Но я написал скрипт пользователя .js в Tampermonkey, чтобы позволить мне более точно контролировать воспроизведение видео в Safari.Я настроил его запуск на всех доменах:

// @include http://*
// @include https://*  

И хотя пока это, безусловно, работает для меня, я знаю, что скрипт без необходимости работает на 80% моего Интернета.делать это не связано с взаимодействием с элементами видео ... Итак, я прошел и скомпилировал исчерпывающий список из ~ 1000 конкретных доменов, где имеет смысл запустить скрипт, например:

// @include     *://*.facebook.com/*
// @include     *://*.vimeo.com/*
// @include     *://*.youtube.com/*

Но послефактически введя 1000 строк этого в мой [ранее довольно миниатюрный!] пользовательский скрипт, меня осенило, что - насколько я знаю - я действительно мог бы значительно увеличить количество системных ресурсов, которое требуетсязапустить этот сценарий, заставив его теперь проходить через длинный список доменов, чтобы увидеть, соответствует ли он ... и что, возможно, просто запустить его по умолчанию может быть менее ресурсоемким?

Ха, в то же времяЯ также могу представить себе, как запустить его везде = очевидно больше пустой траты ресурсов ... Но так как я понятия не имею, как бы я вообще смог протестировать это (и у меня, конечно, нет достаточного понимания основополагающей теории здесь) -> Я думал, что оставлю это на усмотрение экспертов и обращусь к вам за советом!

Спасибо затвоя помощь!!:-)

Answer 1

Частичный ответ, потому что он слишком велик для комментария, а также потому, что у меня нет желания настраивать и проводить какие-то новые эксперименты прямо сейчас.(Если кто-то отправляет ответ с обновленными, проверяемыми номерами, он получает мое одобрение.)

Вот примерный план того, что происходит, когда у вас есть Tampermonkey, Violentmonkey и т. Д. И установлены пользовательские скрипты:

1. Каждая посещаемая вами страница проверяется на соответствие директивам @include, @match и @exclude для каждого активного пользовательского скрипта .Более умные движки сначала проверяют @exclude и останавливаются, если найдено совпадение.

   Некоторые движки лучше справляются с этой проверкой, чем другие, и, в идеале, информация о совпадении сайта будет храниться в памяти для максимальной скорости.

2. Каждый <frame> или iframe на всех посещаемых вами страницах проверяются на соответствие директивам @include, @match и @exclude каждого активного пользовательского сценария., если в этом сценарии не установлено @noframes.

3. Если скрипт соответствует странице (или фрейму), то Tampermonkey (и т. Д.) Должен:
   (A) получить код скрипта и любые данные - часто с диска(медленно).
   (B) Затем создайте некоторый уровень песочницы - в зависимости от движка, браузера и режима @grant.
   (C) Вставьте скрипт в вышеупомянутую песочницу - почти всегдаобернута анонимной функцией - и запустите ее.

4. Затем пользовательский скрипт будет использовать ресурсы в зависимости от своего кода.

В целом:

1. @match работает лучше (проверено годами ранее), чем @include.Если вы собираетесь использовать 1000 строк, используйте @match сверх включая.

2. Используйте @noframes, если у вас нет причин не делать этого.

3. Шаги1 и 2 в идеале могут быть выполнены все из памяти (нужно посмотреть, что в данный момент делают различные движки), и лот из @include с может быть обработан в то же время, которое требуется для внедрения одного пользовательского скрипта.(Кто-нибудь хочет попробовать собрать какие-нибудь числа?)
4. Если пользовательский скрипт или его данные (@require файлы, @resource файлы, GM_setValue данные) должны быть извлечены с диска, то это сравнительноогромная задержка во времени.(Но все же это быстрее, чем извлекать информацию из Интернета.)

Наконец, временные усилия и возможный стресс из-за необходимости поддерживать большой список сайтов, редактируя файл usercript каждыйвремя должно быть по сравнению с тем, насколько инвазивен ваш сценарий .

Если бы это был я, и сценарий задерживал страницы менее чем на 300 миллисекунд, я бы просто держал носи используйте:

// @match    *://*/*
// @noframes

Однако, если сценарий более инвазивен, медленнее или требует больше ресурсов, вы можете использовать гибридный подход ...
Сохранить список сайтов на полностью работает в GM_setValue данных и / или @resource d файле.

Таким образом, вы можете редактировать список на лету, используя, например, команды меню;или через редактор данных скрипта Tampermonkey;или даже с помощью кнопок, которые вы создаете для этой цели.Однако все это выходит за рамки этого вопроса.