как сделать так чтобы скрипты работали

Как и где подключить скрипт?

Доброго времени суток. 🙂

Данная статья не столько материал о котором хочется поговорить, а универсальная инструкция для многих статей на моем сайте. Хочу один раз расписать подробно, как подключать скрипт на сайте, где это можно сделать и как лучше. Если вы на моем сайте бываете часто и используете материалы из статей, то замечали, что в каждой статье где идет упоминание о добавлении скриптов, я постоянно пишу о том где их вставить. Мне надоело повторять одно и то же, легче будет добавлять ссылку на эту статью. У меня уже была схожая статья Как подключить скрипты и где лучше это сделать. Тогда я не полностью раскрыл данный вопрос. Удалять старую статью или переписывать не хочу, поэтому создам новую. Не будем затягивать и приступим.

Где подключать скрипты?

Если у вас имеется элемент для сайта, который использует javascript, jQuery и его библиотеки, то их нужно будет подключить. Обычно все подключается в шапке сайта перед закрывающимся head или в подвал перед закрывающимсяbody. Тут стоит выбирать вам и опираться на задачу и обстоятельства.

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

Хочу отдельно упомянуть про WordPress. В шапке подключайте свои скрипты после wp_head();. В подвале имеется функция wp_footer();, все подключения после нее. В зависимости от настроек эти функции выводят библиотеку jQuery и другие скрипты WordPress, после которых и следует подключать свои. хотя если у вас простенький javascript код, то можно и не придерживаться этого правила.

Как подключать скрипт?

По этому принципу подключается и библиотека jQuery. Обычно это выглядит так:

Следует учесть, что нельзя подключать несколько библиотеки jQuery. Если это сделано уже ранее, то не следует повторять. Внимательно просматривайте код на наличие такого подключения. Чаще всего, в системах управления сайтами, типа WordPress, библиотека подключена по умолчанию. Не всегда можно найти в файлах такую строку, нужно смотреть через браузер. Опять, в том же WordPress библиотека выводится в wp_head(); или wp_footer();, о которых я упомянул выше, в зависимости от настроек.

Библиотека jQuery по коду должна быть первой, а скрипты что нуждаются в ней должны быть размещены после нее. Простые java скрипты этому правилу не подчиняются, только jQuery. Запомните это правило. Оно поможет избежать вам в будущем множества проблем.

Но если он занимает большой объем, занимать им место на странице, как по мне не разумно и не удобно.

В один файл можно размещать множество скриптов. Лично я часто пользуюсь таким методом. Причем одновременно можно добавлять как и обычный javascript, так и jQuery скрипты.

После того, как скрипт или скрипты в файл добавлены, его подключаем так же как и библиотеку. С помощью тегов указывая путь к файлу. Файл, естественно заливаете на сайт в папку с другими файлами сайта. В какую именно, решать вам, в зависимости от того какая система у вас или как вы захотите. Например, вы создали рядом с файлом где HTML код, папку с названием js и в нее поместили наш файл.

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

Подключение скриптов в WordPress

Разберем функцию по-порядку:

Помните я в начале говорил о том, что можно настроить вывод в подвале и в шапке. Данная функция по умолчанию выведет скрипт в шапке. Чтобы добавить в подвал нужно добавить в строку с подключением еще один параметр.

Если Вы захотите подключить 2 файла то функция будет такой:

Так же, с помощью такой функции можно подключать и библиотеку jQuery. Но есть один момент. По умолчанию WordPress уже использует библиотеку, поэтому вторую так просто нельзя подключать, нужно отключить старую.

лично я всегда отключаю встроенную библиотеку и подключаю от Google. Делается это следующим образом. В примере будет и переподключение библиотеки и подключение файла со скриптом, чтобы вы видели как это выглядит и понимали что все просто и по тому же принципу.

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

Сжатие скриптов

Несмотря на то, как вы подключили скрипт, вы можете облегчит его загрузку браузером. Обычно скрипт имеет вот такой вид:

Согласитесь, читать такой скрипт легко и удобно, понятно и не напряжно. Но если такой понятный скрипт занимает 100 строк. В нем тысячи пробелов, комментариев и прочего ненужного хлама, что не влияет на скрипт. Но браузеру нужно немного больше времени чтобы его загрузить. А если таких скриптов больше десятка? Нагрузка на сайт увеличивается и время его загрузки тоже. А если скрипт станет таким?

Не плохо правда? Всего одна длинная строка, но намного меньше по объему. Читать такой скрипт сложнее, но если вам не нужно его постоянно править, вы настроили его один раз и все, то такое сжатие принесет только плюсы. Чтобы сделать это, можно помучатся вручную или воспользоваться любым сервисом по сжатию java скриптов.

После сжатия и правильного подключения ваши скрипты будут отлично работать и минимально нагружать сайт.

На этом все, спасибо за внимание. 🙂

Если Вам был полезным мой труд, можете финансово поддержать сайт или отключить блокировщик рекламы, что займет 2 минуты 🙂

Источник

Запуск скрипта после загрузки страницы (DOM)

Есть скрипт, который должен запуститься после загрузки DOM, так как в нём есть обращение к DOM:

Как мне запустить данный скрипт, чтобы обращение скрипта к DOM сработало?

2 ответа 2

Для тех, кто не знает, почему не работают скрипты с обращением к элементам вида :

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

Особенность языка Javascript в том, что его код выполняется последовательно, строка за строкой, как они написаны в исходном коде.

Варианты решения данного вопроса:

Один из простых способов ― перенести в body после всех элементов. При таком расположении сначала загрузится DOM, а потом скрипт. Пример:

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

Ещё одним минусом является то, что нельзя указывать несколько функций таким образом. Т.е. если вы два раза использовали window.onload в коде, то вторая функция сотрёт первую. Но, чтобы это исправить, я сочинил интересный костыль:

Интересный вариант ― что-то между первым и вторым пунктом. Создать особую функцию и вызывать её через скрипт в конце body. Пример:

Поддержка этого метода начинается с IE9+

Ну и подошли варианты с библиотеками. И первая наша библиотека JQuery ScriptJava. Пример:

Самый действенный вариант ― самописная функция со enStackOverflow. Работает в IE8:

var ready = (function()<

> // The DOM ready check for Internet Explorer function doScrollCheck()

И наконец самый странный и не всегда рабочий вариант ― использовать setTimeout. Пример:

Это все варианты, которые я встречал, но возможно не единственный, так как другие программисты могли придумать свои функции для решения данной задачи.

Источник

Погружение в темные воды загрузки скриптов

Введение

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

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

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

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

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

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

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

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

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

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

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

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

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 документа:

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

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

С появлением HTTP2/SPDY вы сможете уменьшить накладные ресурсы до точки, где доставка скриптов в маленьких самостоятельно-кэшированных файлах будет самым быстрым способом. Только представьте:

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

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

У IE есть идея!

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

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

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

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

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

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

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

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

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

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

Defer

Спецификация говорит: Скачивай вместе, выполняй по порядку до DOMContentLoaded. Игнорируй «defer» для скриптов без «src».
IE

Источник

Bash-скрипты, часть 5: сигналы, фоновые задачи, управление сценариями

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

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

Сигналы Linux

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

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

Bash-скрипты не контролируют эти сигналы, но они могут распознавать их и выполнять некие команды для подготовки скрипта к последствиям, вызываемым сигналами.

Отправка сигналов скриптам

Оболочка bash позволяет вам отправлять скриптам сигналы, пользуясь комбинациями клавиш на клавиатуре. Это оказывается очень кстати если нужно временно остановить выполняющийся скрипт или завершить его работу.

Завершение работы процесса

Комбинация клавиш CTRL + C генерирует сигнал SIGINT и отправляет его всем процессам, выполняющимся в оболочке, что приводит к завершению их работы.

Выполним в оболочке такую команду:

Завершение работы процесса с клавиатуры

Временная остановка процесса

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

Если вы приостановите задание, привязанное к оболочке, и попытаетесь выйти из неё, bash выдаст предупреждение.

Просмотреть приостановленные задания можно такой командой:

Выглядит её вызов так:

Перехват сигналов

Команда trap позволяет скрипту реагировать на сигналы, в противном случае их обработка выполняется оболочкой без его участия.

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

Перехват сигнала выхода из скрипта

Перехватить сигнал выхода из скрипта можно, использовав при вызове команды trap имя сигнала EXIT :

Перехват сигнала выхода из скрипта

Модификация перехваченных сигналов и отмена перехвата

Для модификации перехваченных скриптом сигналов можно выполнить команду trap с новыми параметрами:

Модификация перехвата сигналов

После модификации сигналы будут обрабатываться по-новому.

И нажмём CTRL + C на клавиатуре.

Сигнал, перехваченный до отмены перехвата

Выполнение сценариев командной строки в фоновом режиме

Иногда bash-скриптам требуется немало времени для выполнения некоей задачи. При этом вам может понадобиться возможность нормально работать в командной строке, не дожидаясь завершения скрипта. Реализовать это не так уж и сложно.

Запустим его, указав после имени символ амперсанда ( & ):

Это приведёт к тому, что он будет запущен как фоновый процесс.

Запуск скрипта в фоновом режиме

Скрипт будет запущен в фоновом процессе, в терминал выведется его идентификатор, а когда его выполнение завершится, вы увидите сообщение об этом.

При таком подходе, если выйти из терминала, скрипт, выполняющийся в фоне, так же завершит работу.

Что если нужно, чтобы скрипт продолжал работать и после закрытия терминала?

Выполнение скриптов, не завершающих работу при закрытии терминала

Применим эту методику при запуске нашего скрипта:

Вот что будет выведено в терминал.

Просмотр заданий

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

Запуск и приостановка скрипта

Запустим тот же скрипт в фоновом режиме, при этом перенаправим вывод скрипта в файл так, чтобы он ничего не выводил на экране:

Получение сведений о скриптах

Перезапуск приостановленных заданий

Теперь скрипт выполняется в фоновом режиме.

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

Для перезапуска задания в обычном режиме воспользуйтесь командой fg :

Планирование запуска скриптов

Вызов команды at выглядит так:

Эта команда распознаёт множество форматов указания времени.

Планирование заданий с использованием команды at

Для того чтобы посмотреть список заданий, ожидающих выполнения, можно воспользоваться командой atq :

Список заданий, ожидающих выполнения

Удаление заданий, ожидающих выполнения

Запуск скриптов по расписанию

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

Crontab выполняется в фоне и, основываясь на данных в так называемых cron-таблицах, запускает задания по расписанию.

При планировании запуска скрипта по расписанию crontab принимает данные о том, когда нужно выполнить задание, в таком формате:

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

Здесь универсальный символ « * », использованный для полей, задающих день месяца, месяц и день недели, указывает на то, что cron должен выполнять команду каждый день каждого месяца в 10:30.

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

Нумерация дней недели начинается с 0, 0 означает воскресенье, 6 — субботу. Вот ещё один пример. Здесь команда будет выполняться в 12 часов дня в первый день каждого месяца.

Затем можно вводить команды формирования расписания:

Благодаря этой команде скрипт будет вызываться ежедневно в 10:30. Если вы столкнётесь с ошибкой «Resource temporarily unavailable», выполните нижеприведённую команду с правами root-пользователя:

Организовать периодический запуск скриптов с использованием cron можно ещё проще, воспользовавшись несколькими специальными директориями:

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

Запуск скриптов при входе в систему и при запуске оболочки

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

Итоги

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

Уважаемые читатели! А вы пользуетесь средствами планирования запуска сценариев командной строки по расписанию? Если да — расскажите пожалуйста о них.

Источник