Факторы производительности Javascript - PullRequest
1 голос
/ 10 сентября 2009

Я понимаю, что браузер выполняет всю работу по обработке клиентских сценариев (Javascript, JQuery и т. Д.), Но хотел знать, имеет ли что-нибудь еще значение, когда речь заходит о производительности (скорость сети, скорость клиентского компьютера, среда сервера)

Если он полностью зависит от браузера (тип и версия), правильно ли говорить, что при первом обращении к странице он работает медленнее, а затем браузер кэширует файл / сценарии JS и с этого момента он работает быстрее?

Может кто-нибудь объяснить, как все это получается вместе?

Ответы [ 4 ]

3 голосов
/ 10 сентября 2009

Все является фактором на некотором уровне.

Большинство сценариев загружаются синхронно, поэтому скорость сети становится большой проблемой, пока сценарий не кэшируется . Вы можете смягчить это до некоторой степени в новых браузерах, если ваш сценарий не изменяет DOM во время загрузки (document.write() ...) и не требуется другим сценариям на странице, но они все еще должны быть загруженным до того, как браузер сможет считать страницу загруженной. Сокращение количества ваших сценариев может помочь им быстрее путешествовать по сети, а настройка вашего сервера для обслуживания сжатых gzip может помочь еще больше ... Но после кэширования это не так уж важно.

Скорость клиентского компьютера напрямую влияет на скорость работы браузера - среды выполнения скрипта. Быстрый браузер по-прежнему будет быстрее запускать скрипты на быстром компьютере.

Быстрая виртуальная машина браузера может иметь огромное значение : современные среды выполнения для JavaScript имеют значительно различных характеристик производительности. Браузеры могут работать быстрее или медленнее в разных областях: быстрая ВМ в сочетании с медленным DOM будут запускать сценарии быстро только до тех пор, пока не начнут вносить серьезные изменения в страницу; быстрый DOM с медленной виртуальной машиной будет гореть, пока скрипт не попытается выполнить нетривиальную обработку. И как только сценарий кэшируется, эти характеристики производительности браузера становятся гораздо более важными - ваше предположение «быстрее после кэширования» остается верным, только если скорость сети изначально является заметным узким местом.

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


Дальнейшее чтение:

0 голосов
/ 11 сентября 2009

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

Движок JavaScript браузера может быть более или менее оптимизирован. Это также влияет на производительность. Прямо сейчас мы наблюдаем конкуренцию среди поставщиков браузеров за «кто может сделать самый быстрый движок JS».

Клиентский компьютер выполняет фактическую обработку, поэтому, чем быстрее компьютер, тем быстрее выполняется сценарий. Попытка запустить интенсивную современную JS на 166 МГц Pentium будет болезненной.

Кроме того, сам код оказывает огромное влияние на производительность. Хорошо написанный Javascript может работать на порядки быстрее, чем плохо написанный Javascript. Мое любимое видео на эту тему здесь: Google Tech Talk: ускорите свой JavaScript

0 голосов
/ 10 сентября 2009

Это зависит от того, что вы делаете, чтобы действительно ответить на этот вопрос.

Например, если ваш процессор занят рендерингом анимационного фильма во время использования приложения javascript, вы увидите более медленную производительность.

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

Тем не менее, браузер важен, так как IE8, например, работает медленнее, чем Chrome, основываясь на следующих тестах: http://www.lifehacker.com.au/2009/09/browser-speed-tests-chrome-40-and-opera-10-take-on-all-challengers/

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

http://www.codinghorror.com/blog/archives/001023.html

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

0 голосов
/ 10 сентября 2009

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

...