Как установить скрипт в браузер

Обновлено: 06.07.2024

Для некоторых юзерскриптов начинает иметь значение, каким способом пользователь установит его в браузер Оперу. Если сделать установку, не разрешив доступ к некоторым доменам, работа будет неполноценной, а при установке кроссдоменного скрипта, да ещё использующего защищённый протокол (HTTPS), такое запросто может случиться. Например, для юзерскрипта HabrAjax, кроме основного сайта Хабра, используется доступ к кнопкам Google Plus на plusone.google.com и проверяются обновления скрипта на домене userscripts.org. Всё это требует дополнительных настроек, которые были описаны прямо в юзерскрипте (ссылка в настройках "примеч.для Оперы"), но сделаны довольно кратко и с одной иллюстрацией. Здесь посмотрим на вопрос шире, чтобы пользователи Оперы и разработчики юзерскриптов для неё имели инструкции под рукой и полностью понимали широту вопроса. Заодно, описаны места установки юзерстилей. Для тех, кто всё это знает, полезно будет посмотреть абзац выводов с 2 замечаниями в самом низу.

Первая особенность работы юзерскриптов в Опере — в том, что для них не работают специальные события BeforeScript, которые отлично работают для обычных скриптов и обеспечивают кроссбраузерность. Поэтому, если мы хотим работать с другим доменом в фрейме, юзерскрипту надо обеспечить доступ к другому домену, а значит, прописать в настройках скриптов для сайтов и основной сайт, и сайт, находящийся в фрейме — строго с соответствии с тем, что прописано в мета-директивах скрипта для остальных браузеров.

Как запустить в Опере простой односайтовый юзерскрипт?

Юзерскрипты в Опере умеют запускать очень много пользователей. Достаточно посмотреть на статистику использования юзерскрипта HabrAjax в браузерах, которые согласились дать 26 человек, то видно, что 8 человек устанавливали скрипт на Оперу (не исключая других браузеров). Кстати, если вы пользовались HabrAjax, прошу пройти голосование в этом опросе: "В каком браузере вы используете HabrAjax?". Он поможет набрать больше статистики.

Для справки, для тех, кто ещё не устанавливал в Опере юзерскрипты, приведена инструкция ниже. Она не самая простая, но весь фокус данной статьи в том, что для защищённых страниц с юзерскриптами она ещё сложнее. Не все также знают, что способов установки скриптов в Опере не один, а два (не считая аддонов); в инструкциях — проиллюстрированы оба. В мобильной Опере (Mobile) также имеются все возможности работы с юзерскриптами и юзерстилями, но настройки разрешения функций могут быть отключены в opera:config и понадобится приверять и их, если что-то не работает (выходит за рамки статьи).

1. Установить юзерскрипт (без механизма аддонов, введённых в 11-й версии) можно в Опере в 2 режимах: для всех сайтов сразу, с задействованием мета-директив скриптов, или для некоторого сайта на одном домене (и таких сайтов может быть много). Юзерскрипты, принятые как фактический стандарт в 2 основных браузерах (Firefox и Chrome), имеют мета-директивы — несколько закомментированных строк, обычно расположенных в начале файла юзерскрипта. В них записываются адреса URL, в которых действуют скрипты, поэтому установка правил работы определяется директивами и требует единственного клика по кнопке «Разрешить установку» в этих браузерах. В Опере изначально было не так, но было лучше, чем на заре введения юзерскриптов, когда в Safari скрипты запускались для всех сайтов сразу, и только действия самого скрипта могли выбрать группу URL, в каких он продолжал работать. Поэтому первый режим (для всех сайтов) — это повторение примитивного способа запуска скриптов, но с улучшениями в плане понимания директив.

Второй способ — прописать настройки для сайтов — уходит в сторону от современного способа настройки юзерскриптов через директивы. Но они оставлены в Опере из-за того, что сайтам можно вручную задавать множество ограничений и особеннстей, в том числе индивидуальные стили и скрипты. Эти 2 способа несколько конфликтуют друг с другом: применение второго блокирует работу первого способа (не запускаются скрипты из общей папки, даже имеющие нужные директивы) для выбранного сайта. Это нужно понимать при прописывании индивидуальных настроек, так как неочевидно. Покажем эту общую информацию с иллюстрациями.

1.а) Открыть браузер и его Общие Настройки (Ctrl-F12 или из меню, как на рисунке).

Здесь и далее будем показывать Оперу 11.61 в ОС WinXP с темой оформления (Shift-F12) Netbook Skin v.11.3 — для компактности:

1.б) Открываем вкладку "Инструменты — Общие настройки — Расширенные — Содержимое — Настроить Javascript" — попадаем в настройки 1-го режима юзерскриптов. Если разместить скрипт в Папке пользовательских файлов, указанной в настройках, он будет выполняться в каждом окне браузера. Если написать директивы include, как обычно для скриптов, с указанием сайтов, он будет фильтроваться директивами в иных сайтах. Совсем без директив оставляют скрипты редко. Не всегда скрипт, написанный для конкретного сайта, может корректно работать везде (ничего не делать на всех чужих сайтах), да и ресурсы на начальный запуск скрипта в каждом окне будут тратиться.

1.в) Аналогично скриптам, имеются настройки общих стилей: для всех сайтов, для каждого окна в "Инструменты — Общие настройки — Расширенные — Содержимое — Настроить стили. ".

Они тоже могут иметь побочные эффекты на не свои сайты, если стиль для конкретного сайта положим в папку для всех сайтов (надпись на скриншоте — "Моя таблица стилей"). Подобная примитивная возможность есть в IE7-9 и Safari. Поэтому для сайтов в Опере сделаны индивидуальные сайтовые настройки для скриптов и стилей.

Индивидуальные настройки скриптов и стилей, имеющиеся только у Оперы среди основных браузеров — это тоже устаревшее и несовременное явление на фоне аддонов, которые Опера поддерживает (с 11-й версии), потому что работы для пользователя по настройкам браузера намного больше, чем при установке аддона.

1.г) Открываем "Инструменты — Общие настройки — Расширенные — Содержимое — Настройки для сайтов. ", чтобы установить скрипты и стили для некоторых сайтов. Так как все другие настройки установлены в обычное положение, требуется обратить внимание на 3 места: название домена, путь к стилям для сайта, путь к скриптам для сайта (к папке скриптов).

Итого, получается, что если для сайта есть хотя бы одна особенность кроме скриптов, например, пользовательские стили, то и скрипты вынуждены писать не в общей папке скриптов с действием директив, а в «Настройках для сайтов». Тогда, если в директивах упомянуто более одного сайта, необходимо и для них прописать настройки для сайтов. Если же скрипт лежит в общей папке скриптов, можно положиться на директивы юзерскрипта — они будут работать.

Закончено общее описание 2 вариантов установки юзерскриптов в Опере и их особенностей. Но есть ещё одна особенность, после которй будет понятно, что трудности интерфейсов браузера только начинаются.

Эта установка доставит немало неприятных минут в дальнейшем. На каждом сайте с HTTPS она будет задавать один и тот же вопрос (при первом заходе на сайт после открывания браузера или после смены скрипта): ". И совершенно неважно, что скрипт пользователя не собирается заглядывать в этот домен. Открываете, скажем, GMail — вопрос будет (первый раз). После перезапуска Оперы — снова.

Неустановки навязчивого параметра нельзя избежать и при запуске скрипта из общей папки — и там требуется это разрешение в настройках.

(Чтобы Опере было не одиноко чувствовать себя среди багов юзерскриптов, в следующей статье разберём баг Хрома (2.5 года от момента его оформления) с доступом к соседнему фрейму и его решение.)

Создание аддона Оперы и проблематика аддонов вообще

Пользователю — тоже удобно работать с одним файлом. По крайней мере, в Firefox и Chrome требуется 2 клика на скачивание и подтверждение установки. В Safari — тоже, хотя NinjaKit кое-в-чём не поддерживает функции GreaseMonkey — среды поддержки юзерскриптов в Firefox, существующей как стандарт де-факто. В Опере, если не делать настройки для сайтов — тоже суеты немного — скопировать файл в общую папку скриптов.

Но, начиная с «кастомизации» (в плохом смысле) по браузерам, становится хуже всем. Пользователю надо знать, что для разных браузеров есть разные места хостинга скриптов. Ему нужно перезапускать браузер в большинстве случаев. Одно удобство — те же 1-2 клика для установки, не считая перезапуска.

Есть ещё шальная мысль — создавать кроссбраузерные аддоны, работающие везде с одним кодом, различающиеся буквами расширений. Это очень подойдёт также Safari, для которого нет полноценной поддержки юзерскриптов (проблемы, например, в реализации кроссдоменного обмена). Правда, для IE7-9 понадобится тоже уникальное решение, идущее назад к юзерскрипту, потому что формат юзерскриптов для аддонов IE — это классический юзерскрипт с большим количеством ограничений и, конечно, различием в логике JS.

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

На этом позволим себе прервать дозволенные речи, а создание аддона разобрать в следующий раз, чтобы завершить тему особенностей создания юзерскриптов для Оперы.

Практические выводы

(Статья — из общего пула статей, порождённых работой с юзерскриптами для Хабра.)

Как упоминалось в предыдущей статье, юзерскрипты поддерживаются всеми современными браузерами. И даже кое-как поддерживаются в IE7 и выше.

Ограничения
Проблемы
Расширения для запуска юзерскриптов
Установка юзерскриптов

Пару слов о движках

Качество поддержки юзерскриптов находится на разном уровне в разных браузерах. Лучше всего поддержка юзерскриптов выполнена в браузерах Firefox и Chrome.
Эти браузеры предоставляют более менее дружелюбные интерфейсы для управления юзерскриптами.

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

Теперь поговорим подробнее о поддержке юзерскриптов в отдельных браузерах.

Поддержка в Firefox

Mozilla Firefox поддерживает юзерскрипты после установки расширения GreaseMonkey (в русском сленге — обезъяна) или Scriptish.
После установки расширений фаерфокс получает поистине мощную поддержку юзерскриптов.
Рассматриваемая далее информация применима в первую очередь к GreaseMonkey (это расширение было первым).

Исторически, все юзерскрипты писались под браузер Firefox именно из-за наличия удобного плагина.
Это обусловливает тот факт, что все браузеры, которые поддерживают юзерскрипты, дополнительно следуют основным правилам спецификации GreaseMonkey по разбору метаданных.
Это означает, что все скрипты, которые были написаны под GreaseMonkey, будут устанавливаться и запускаться в браузерах, поддерживающих юзерскрипты (с минимумом модификаций).

К сожалению, ни один браузер, кроме Firefox, не предоставляет GM API. Этот печальный факт заставляет использовать эмуляции GM API через расширения или дополнительные юзерскрипты.

В случае разработки юзерскрипта «с нуля», я считаю предпочтительным отказаться от эмуляции GM API и использовать «велосипеды» собственного производства. Это позволяет уменьшить число зависимостей юзерскрипта, что, в свою очередь, позволяет вести разработку в рамках концепции одного файла: модифицировать придётся всего один файл; пользователю нужен всего один файл для запуска юзерскрипта.

Концепция одного файла позволяет существенно уменьшить сложность поддержки и кроссбраузерной разработки юзерскриптов!

Поддержка в Chrome

Google Chrome поддерживает юзерскрипты нативно, т.е. не требует установки плагинов/расширений. Можно (иногда нужно) упаковать юзерскрипт в расширение.

Не доступен document.frames[i].parent (разрешено в расширении).
Не доступны объекты родного окна, к примеру window.page_defined_var (подменить функции страницы будет нельзя, JSONP в юзерскрипте тоже отпадает)
Не доступны кроссдоменные запросы (разрешены в расширении)
unsafeWindow доступен, но не несёт функциональности GM API.
Удобный нативный debug юзерскриптов и расширений.

manifest.json — файл описания расширения. Аналог метаданных юзерскрипа.
background.html — файл «фоновой страницы» расширения. Даёт доступ к API расширений через вызов методов chrome.extension.*

Важно: фактически, расширение и юзерскрипт — разные понятия. И если подходить к вопросу строго, стоит говорить о разработке простых расширений под Chrome.
В случае, когда юзерскрипт требует нестандартного, «тяжелого» функционала, он требует упаковки в расширение.
Для упаковывания юзерскрипта в расширение нужно проделать дополнительные действия один раз. Вся последующая разработка будет вестись в рамках концепции одного файла.

Поддержка в Opera

Opera поддерживает юзерскрипты нативно, но не предоставляет сколь-нибудь дружелюбного пользовательского интерфейса для управления скриптами. Такой интерфейс доступен в расширении UJS Manager.

Юзерскрипты запускаются «как есть», не оборачиваясь в замыкание, тем самым засоряя глобальную область видимости window.
Доступны объекты родного окна, к примеру window.page_defined_var.
Доступные специфические события браузера Opera, к примеру BeforeScript.
Не доступны кроссдоменные запросы (Обходится использованием специальных событий)
unsafeWindow недоступен.
Скрипты запускаются в алфавитном порядке.

Поддержка в IE

IE7, IE8, IE9 поддерживают юзерскрипты при использовании плагина Trixie.
К тому же, имеется более продвинутый плагин IE7Pro. В IE7Pro помимо поддержки юзерскриптов имеется множество других ~~бес~~полезных возможностей.

Важно: Если не отключать дополнительные «приблуды» в IE7Pro, то плагин может изрядно тормозить браузер, особенно на тяжёлых страницах.

Как видите, с запуском скриптов у IE дела обстоят паршиво. Остаётся радоваться, что такая возможность вообще имеется.

Важно: Оба плагина могут существовать в системе одновременно, не мешая друг другу.

Важно: Учитывая вышесказанное, я всегда предлагаю своим пользователям использовать Trixie.

Поддержка в Safari

К сожалению, мне не довелось поработать с данным браузером. Буду рад любым разъяснениям в комментариях!
Поговаривают, что для Safari нужны SIMBL и плагин GreaseKit.

Поддержка в Mobile Safari и прочих браузерах

В виду отсутствия поддержки юзерскриптов в менее популярных браузерах и мобильных браузерах, юзерскрипты придётся предоставлять в виде букмарклета.
Соотстветственно, метаданные в таком случае не нужны, а букмарклет придётся запускать руками после каждого рефреша.

Введение

В этой статье я хочу научить вас как загружать в браузер JavaScript и выполнять его.

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

Для затравки, вот как спецификация определяет различные способы загрузки и выполнения скриптов:

Как и все спецификации WHATWG, на первый взгляд данная спецификация выглядит как последствия кассетной бомбы на фабрике Scrabble. Но, прочитав ее на 5 раз и вытерев кровь из своих глаз, начинаешь находить ее довольно интересной:

Мое первое подключение скрипта

Ах, блаженная простота. В данном случае браузер скачает оба скрипта параллельно и выполнит их как можно скорее, сохраняя заданный порядок. «2.js» не будет выполняться пока не выполнится «1.js» (или не сможет этого сделать), «1.js» не выполнится пока не выполнится предыдущий скрипт или стиль, и т.д. и т.п.

К сожалению, браузеры блокируют дальнейшую отрисовку страницы, пока это все происходит. Еще со времен «первого века веба» это обусловлено DOM API, который позволяет строкам добавляться к содержимому, которое пережовывает парсер, например с помощью document.write . Более современные браузеры продолжат сканировать и парсить документ в фоновом режиме и загружать нужный сторонний контент (js, картинки, css и т.д.), но отрисовка по-прежнему будет блокирована.

Вот почему гуру и специалисты производительности советуют размещать элементы script в конце документа, потому что это блокирует меньше всего контента. К сожалению, это означает, что ваш скрипт не будет увиден браузером до того времени, как будет скачен весь HTML, а также уже запущена загрузка CSS, картинок и iframe-ов. Современные браузеры достаточно умны, чтобы отдавать приоритет JavaScript над визуальной частью, но мы можем сделать лучше.

Спасибо, IE! (нет, я это без сарказма)

В Microsoft обнаружили эти проблемы с производительностью и ввели «defer» в Internet Explorer 4. В основном, оно говорит следующее: «Я обещаю ничего не вставлять в парсер, используя штуки, наподобие document.write . Если я нарушу это обещание, вы можете меня наказать любым приемлемым вам способом». Этот атрибут был введен в HTML4 и он также появился в других браузерах.

В примере выше, браузер параллельно скачает оба скрипта и выполнит их прямо перед тем, как вызовется DOMContentLoaded , порядок сохранится.

Как и кассетная бомба на фабрике овец, «defer» стал мохнатым беспорядком. Помимо «src» и «defer», а также тегов скрипт и динамически загружаемых скриптов, у нас есть 6 паттернов добавления скрипта. Естественно, что браузеры не договорились о порядке, в котором они должны выполняться. Mozilla замечательно описала эту проблему еще в 2009.

WHATWG сделали это поведение явным, объявив, что «defer» не будет иметь никакого эффекта на скрипты, которые были добавлены динамически или не имеют «src». В противном случае, скрипты с «defer» должны запускаться в заданном порядке после того, как документ был распарсен.

Спасибо, IE! (ну ладно, теперь с сарказмом)

Одно дали — другое отобрали. К сожалению, есть неприятный баг в IE4-9, который может спровоцировать выполнение скриптов в неверном порядке. Вот что происходит:

Допустим, что на странице есть параграф, ожидаемый порядок логов — [1, 2, 3], но в IE9 и ниже результат будет [1, 3, 2]. Некоторые операции DOM вынуждают IE приостановить выполнение текущего скрипта и перед продолжением начать выполнение других скриптов в очереди.

Тем не менее, даже в реализациях без бага, таких как IE10 и других браузерах, выполнение скрипта будет отложено до момента, когда весь документ будет загружен и распарсен. Это удобно, если вы в любом случае ждете DOMContentLoaded , но если вы хотите получить реальный прирост производительности, то вскоре вы начнете использовать listeners и bootstrapping…

HTML5 спешит на помощь

HTML5 дал нам новый атрибут «async», который предполагает, что вы также не используете document.write, но при этом не ожидает окончания парсинга документа. Браузер параллельно скачает оба скрипта и выполнит их как можно скорее.

К сожалению, так как они постараются выполниться максимально скоро, «2.js» может выполниться раньше «1.js». Это отлично, если они не зависят друг от друга. Например, если «1.js» — это отслеживающий скрипт, не имеющий ничего общего с «2.js». Но если «1.js» — это CDN-копия jQuery, от которой зависит «2.js», то ваша страница будет устлана ошибками, как после кассетной бомбы в… я не знаю… здесь я ничего не придумал.

Я знаю, нам нужна JavaScript-библиотека!

В Святом Граале содержится набор скриптов, загружающихся сразу, без блокирования отрисовки страницы и выполняющихся максимально скоро, в том порядке, в котором мы их добавили. К сожалению, HTML ненавидит вас и не позволит вам этого сделать.

Проблема была решена с помощью JavaScript на разный манер. Некоторые способы требовали от вас вносить изменения в JavaScript, оборачивать всё в callback, который библиотека вызовет в правильном порядке (например, RequireJS). Другие использовали XHR для параллельной загрузки, а затем eval() в нужном порядке, который не работает для скриптов на другом домене, если там нет заголовка CORS и поддержки его в браузере. Некоторые использовали даже супер-магические хаки, как это было сделано в последнем LabJS.

Хаки всяческим образом обманывали браузер, чтобы тот загружал ресурс, вызывая при этом событие по окончанию загрузки, но не начинал его выполнение. В LabJS скрипт сначала добавлялся с некорректным mime-типом, например
Скрипты, которые созданы и добавлены динамически, асинхронные по-умолчанию, они не блокируют отрисовку и выполняются сразу после загрузки, что означает, что они могут появиться в неверном порядке. Однако мы можем явно пометить их неасинхронными:

Это даст нашим скриптам сочетание с поведением, которое не может быть достигнуто чистым HTML. Явно заданные неасинхронными, скрипты добавляются в очередь на выполнение, такую же, как они попадали в нашем первом примере на чистом HTML. Однако, создаваемые динамически, они будут выполняться вне парсинга документа, что не будет блокировать отрисовку, пока они будут загружаться (не путайте неасинхронную загрузку скрипта с синхронным XHR, что никогда не является хорошей вещью).

Скрипт выше должен быть встроен в head страниц, начиная очередь загрузок как можно раньше, без нарушения постепенной отрисовки, и начиная выполнять как можно раньше, в заданном вами порядке. "2.js" может свободно загружаться до "1.js", но он не будет выполнен до тех пор, пока "1.js" успешно не скачается и выполнится или не сможет сделать что-либо из этого. Ура! Асинхронная загрузка, но выполнение по порядку!

Загрузка скриптов этим методом поддерживается везде, где поддерживается атрибут async, за исключением Safari 5.0 (на 5.1 все хорошо). Кроме того все версии Firefox и Opera, которые не поддерживают атрибут async, все равно выполняют динамически-добавленные скрипты в правильном порядке.

Это самый быстрый способ загружать скрипты, так? Так?

Ну если вы динамически решаете какие скрипты загружать — да, иначе — возможно, что нет. В примере выше браузер должен распарсить и загрузить скрипт, чтобы определить какие скрипты загружать. Это скрывает ваши скрипты от сканеров предзагрузки. Браузеры используют эти сканеры для обнаружения ресурсов, которые вы скорее всего посетите следующими и для обнаружения ресурсов страницы пока парсер заблокирован другим ресурсом.

Мы можем добавить обнаружаемость обратно, поместив это в head документа:

Это сообщает браузеру о том, что страница требует 1.js и 2.js и видима для предзагрузчиков. link[rel=subresource] похож на link[rel=prefetch] , но с другой семантикой. К сожалению, это поддерживается только в Chrome, и вам нужно объявлять скрипты для загрузки дважды: первый — в элементах link, второй — в вашем скрипте.

Эта статья меня удручает

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

Каждый enhancement-скрипт имеет дело с конкретным компонентом страницы, но требует вспомогательные функции в dependencies.js. В идеале, мы хотим загрузить все асинхронно, затем выполнить enhancement-скрипт как можно раньше, в любом порядке, но после dependencies.js. Это прогрессивное прогрессивное улучшение!

К сожалению, нет декларативного способа для того, чтобы достичь этого, только если модифицировать сами скрипты для отслеживания состояния загрузки dependencies.js. Даже async=false не решит эту проблему, потому что выполнение enhancement-10.js будет заблокировано на 1-9. По факту, есть только один браузер, в котором можно достичь этого без хаков…

У IE есть идея!

IE грузит скрипты не так, как другие браузеры.

IE начинает закачивать "whatever.js" сейчас, другие же браузеры не начнут загрузку до того момента, пока скрипт не будет добавлен к документу. У IE также есть событие "readystatechange" и свойство "readystate", которые сообщают о процессе загрузки. Это на самом деле очень полезно, потому что позволяет нам управлять загрузкой и выполнением скриптов независимо друг от друга.

Мы можем строить сложные модели зависимости, выбирая когда добавлять скрипты в документ. IE поддерживает такую модель, начиная с 6-ой версии. Довольно интересно, но у этого есть такой же недостаток с обнаруживаемостью браузером, как и у async=false .

Хватит! Как я должен загружать скрипты?

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

Именно этот. В конце элемента body. Да, быть веб-разработчиком — это как быть царем Сизифом (бум! 100 хипстерских очков за упоминание греческой мифологии!). Ограничения HTML и браузеров не позволяют нам сделать сильно лучше.

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

Иуу, должно быть что-то получше, что мы можем использовать сейчас?

Ладно, ради бонусных очков, если вы всерьез думаете о производительности и не боитесь сложности и дублирования, то можете объединить несколько рассмотренных трюков.

Во-первых, мы добавим объявление subresource для предзагрузчиков:

Затем прямо в head документа мы загружаем наши скрипты с помощью JavaScript, используя async=false , уступая место скрипту для IE на основе readystate, который, в свою очередь, уступает место defer.

Несколько трюков, затем минификация, и вот 362 байта + URL ваших скриптов:

Стоят ли того дополнительные байты, в сравнении с простым подключением скриптов? Если вы уже используете JavaScript для условной загрузки скриптов, как это делает BBC, то вы можете также получить выигрыш от раннего запуска этих загрузок. В противном случае, скорее нет, придерживайтесь простого способа с подключением в конце body.

Уф, теперь я знаю почему раздел WHATWG по загрузке скриптов такой огромный. Мне нужно выпить.

Краткий справочник

Простые элементы script

Спецификация говорит: Скачивай вместе, выполняй по порядку после любого ожидающего CSS, блокируй отрисовку, пока не закончишь
Браузер отвечает: Да, сэр!

Defer

Спецификация говорит: Скачивай вместе, выполняй по порядку до DOMContentLoaded. Игнорируй "defer" для скриптов без "src".
IE < 10 отвечает: Возможно, что я выполню 2.js в середине выполнения 1.js. Это же весело??
Браузеры красной зоны отвечают: Я понятия не имею что такое defer, я буду загружать скрипты так, как будто этого нет.
Остальные браузеры отвечают: Хорошо, но возможно, что я не буду игнорировать "defer" для скриптов без "src"

Async

Спецификация говорит: Скачивай вместе, выполняй в любом порядке, в котором они закачиваются.
Браузеры красной зоны отвечают: Что такое "async"? Я буду скачивать скрипты так, как будто этого нет.
Остальные браузеры отвечают: Да, хорошо.

Async false

Спецификация говорит: Скачивай вместе, выполняй по порядку, когда все загрузятся.
Firefox < 3.6, Opera отвечают: Я понятия не имею что такое "async", но так случилось, что я выполняю скрипты, добавленные через JS, в порядке, в котором они были добавлены.
Safari 5.0 отвечает: Я понимаю "async", но не знаю как установить его в false через JS. Я выполню ваши скрипты тогда, когда они придут, в любом порядке.
IE < 10 отвечает: Понятия не имею об "async", но есть обходной путь с использованием "onreadystatechange".
Другие браузеры красной зоны отвечают: Я не понимаю "async", я выполню ваши скрипты тогда, когда они придут, в любом порядке.
Остальные отвечают: Я твой друг, мы сделаем это как по учебнику.

На нашем сайте опубликовано уже множество различных Java-скриптов для социальных сетей. И в описании каждого скрипта описывать подробные инструкции по их запуску… Это ни к чему. Мы решили написать полноценный мануал с описанием установки скриптов на все браузеры, а также учесть наличие нескольких способов установки на один конкретный браузер и описать их все.

Запуск Java-скриптов через консоль браузера

Сейчас, как известно, запуск скриптов через консоль является наиболее популярным и простым, а главное рабочим способом их использования. Следовательно, с этого мы и начнём – со способов попасть в консоль для каждого браузера.

Консоль в Mozilla Firefox

Проще всего попасть в веб-консоль в браузере Mozilla Firefox можно при помощи сочетания клавиш Ctrl + Shift + K. Нажмите и консоль отобразится.

Консоль в Google Chrome и других браузерах, основанных на Chromium

В Google Chrome, Opera 15+, Амиго, Orbitum и других браузерах, основанных на Chromium, также имеется способ запуска веб-консоли при помощи горячих клавиш. Для этого нужно одновременно нажать Ctrl + Shift + J.

Консоль в Opera 12

Чтобы запустить веб-консоль в браузере Opera старого поколения (не старше 12-ой версии), нужно использовать сочетание клавиш Ctrl + Shift + I. Это позволит запустить Opera Dragonfly – панель с инструментами для разработчика. После её открытия перейдите на вкладку Консоль.

Консоль в Internet Explorer

Чтобы открыть консоль в веб-браузере Internet Explorer, необходимо сначала нажать на кнопку F12, а затем нажать сочетание Ctrl + 2 (двойка на центральной панели, а не в секции Num).

Консоль в Safari

В Safari, перед открытием консоли, обязательно нужно войти в настройки браузера (шестерёнка в правом верхнем углу » Настройки… » Дополнения) и подключить опцию Показывать меню «Разработка» в строке меню. После этого, консоль можно будет вызывать сочетанием клавиш Ctrl + Alt + C.

Все скрипты вводятся в консоли в специально отведённое поле рядом с иконкой-стрелочкой (см. скриншоты, зоны для ввода скриптов выделены красной рамкой). Запуск скриптов осуществляется нажатием кнопки Enter. После ввода и запуска любого скрипта вы будете видеть все комментарии или ошибки в ходе их выполнения.

Запуск Java-скриптов из адресной строки браузера

Метод запуска скриптов из адресной строки браузера является более старым методом, а скорее даже традиционным. Изначально, все скрипты запускались именно таким образом. Но тенденции меняются, мир развивается. В большинстве браузеров после вставки кода скрипта в адресную строку нужно дописывать код вручную, чтобы запустить, а в некоторых браузерах адресная строка вообще не обрабатывает java-скрипты.

Адресная строка в Mozilla Firefox

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

Адресная строка в Google Chrome и других браузерах, основанных на Chromium

В браузере Google Chrome и любом другом браузере, построенном на его исходных кодах, таких, например, как Opera 15+, Amigo, Orbitum и других, можно запускать скрипты в адресной строке. Но! После вставки скрипта, перед ним обязательно нужно дописывать слово javascript: (вместе с двоеточием), иначе (благодаря такому явлению, как omnibox) вместо запуска скрипта будет происходить перенаправление на поисковую систему.

Адресная строка в Opera 12

В браузере Opera 12 всё обстоит намного лучше. Для запуска скрипта достаточно вставить его в адресную строку и запустить. Никаких проблем при этом возникать не должно.

Адресная строка в Internet Explorer

В данном браузере, как и в Google Chrome и ему подобных, после вставки скрипта в адресную строку, в самом начале нужно дописать javascript: (вместе с двоеточием), иначе скрипт не заработает.

Адресная строка в Safari

Ну а в Safari дела обстоят так же хорошо, как и в Opera 12. Просто вставьте имеющийся скрипт в адресную строку и запустите.

Использование браузерных плагинов для хранения и запуска скриптов

Если скрипты нужно использовать постоянно, то необходимо возиться с ними, копировать с сайта или текстового файла, вставлять в адресную строку или консоль каждый раз. Согласитесь, – это не удобно. Именно поэтому были придуманы специальные расширения (плагины) для браузеров, предназначенные для хранения и запуска скриптов. Речь пойдёт о двух плагинах: Greasemonkey для Mozilla Firefox и Tampermonkey для Google Chrome.

Плагин Greasemonkey для Mozilla Firefox

Плагин Greasemonkey для Mozilla Firefox позволяет создавать, сохранять и запускать скрипты, добавленные пользователями. Будьте внимательны! При использовании скриптов для удаления или изменения чего-либо, сразу после их добавления в плагин они будут запущены автоматически. Настоятельно не рекомендуем добавлять в плагин скрипты, к примеру, для удаления записей со стены ВКонтакте при открытой странице ВКонтакте (мало ли что).

устанавливаем расширение из магазина Mozilla
кликаем на стрелочку рядом со значком плагина в правом верхнем углу браузера
кликаем на Создать скрипт…

Плагин Tampermonkey для Google Chrome

Плагин Tampermonkey является аналогом плагина Greasemonkey для Firefox и точно также позволяет создавать, сохранять и запускать пользовательские скрипты. Будьте внимательны! При использовании скриптов для удаления или изменения чего-либо, сразу после их добавления в плагин они будут запущены автоматически. Настоятельно не рекомендуем добавлять в плагин скрипты, к примеру, для удаления записей со стены ВКонтакте при открытой странице ВКонтакте (мало ли что).

устанавливаем расширение из магазина Google
кликаем на значок плагина в правом верхнем углу браузера
кликаем на Добавить новый скрипт…

Заключение

Все описанные способы запуска Javascript описаны для самых последних версий популярных веб-браузеров. Если вы используете другой браузер или более устаревшую версию браузера, и способы запуска скриптов в нём отличаются от описанных в данной статье, просьба сообщить об этом в комментариях.

Читайте также: