Вопрос по html, testing, performance, javascript – Как вы делаете тесты производительности страницы?

8

Я знаю, что все, кто прочитает вопрос, подумают "Firebug!" сразу. Может быть, некоторые подумают "YSlow!" и & quot; Скорость страницы Google! & quot;

Хотя мне действительно нравятся эти инструменты, меня больше интересует, как быстро будет отображаться страница в IE 6/7/8. Все вышеперечисленные инструменты требуют Firefox. Это все хорошо, и вы определенно можете проверить основную скорость загрузки страницы в браузер, но как насчет того, когда дело доходит до рендеринга страницы?

Я не видел действительно хороших ответов о том, как протестировать оптимизацию на уровне браузера. Как вы пишете тесты производительности для HTML / JS в разных браузерах?

Ваш Ответ

7   ответов
4
Очень хорошо! Сначала я услышал об этих версиях. Travis
5

что это полезная попытка оптимизировать только для одного поставщика:

regarding HTML, most browsers are written to optimize for standard layout techniques (tables, table-less, etc.) the rendering engines are quite different between IE6 and IE8, so already that is like two different browsers most of the techniques for optimizing are standard across browsers (put javascript at bottom so you don't block page loads, move javascript to external file, use multiple hostnames for images etc. to take advantage of parallel loading, don't use tables for overall layout, make sure caching headers are correct, etc.) once you have a site optimized for Firefox, I would argue there is little more to be gained as far as tweaking it for IE; there is probably more you can do at the application level at this point (optimize queries, etc.), unless your site is largely static content, in which case you can investigate caching, HTTP compression, etc. if your concern is actually in optimizing Javascript code for IE, then there are many good cross-browser Javascript libraries that are in an arms-race for best execution times across browser platforms, so again, picking a cross-browser solution is the way to go the browser landscape is constantly evolving, and your customers are likely to move on to another platform at some point down the road; optimizing for several different browsers now will end up with more compatible code that is more likely to perform well when a platform change is made at some point in the future I would argue that writing cross-browser optimized code will result in a more maintainable code base with fewer magic IE hacks, whose reason for existence will soon be lost in the mists of time
правильно, вся таблица должна быть загружена до того, как она будет отображена
"не использовать таблицы для общего макета"; - Зачем?
+1, за упоминание того, что оптимизации являются стандартными для всех браузеров ...
@Midhat - Таблицы с вычисленным макетом требуют, чтобы все их содержимое было разложено и рассчитано, прежде чем какая-либо часть может быть визуализирована. Это скорее вопрос воспринимаемой производительности, чем реальной, но иногда она имеет большое значение.
1

use tools like wget to measure time in which a page is fetched use tools like firebug to measure overall speed difference gives you time taken by the browser

Хотя это может быть не вполне удовлетворительный ответ, я отмечу, что это самый простой.

Кстати, как вы думаете, какие аспекты производительности вы можете выделить, используя «тест уровня браузера»? что вы не можете с помощью «теста уровня firebug»?

Ура,

JRH

Я предполагаю, что часть, которую я чувствую, я пропускаю, - то, как Трайдент делает против Геккона. Travis
0

AOL 's PageTest инструмент, он сочетает в себе множество утилит, найденных в Firebug, YSlow и PageTest, и упаковывает их в приятный веб-интерфейс с несколькими приятными функциями. Во-первых, он может быть запущен на IE7 или IE8 (нет 6, извините) из США или других стран, чтобы дать вам лучшее представление о производительности там. Он предоставляет диаграммы водопадов, подобные тем, что на панели сети Firebug, которые полезны для определения времени, проведенного в сети. Он также предоставляет рекомендации по исправлению, которые аналогичны тем, которые есть в YSlow. Наконец, он позволяет вам запускать несколько испытаний на одном сайте, чтобы вы могли получить более точные результаты при минимизации внешних факторов.

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

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

4
это не больше о производительности движка javascript, чем производительности движка рендеринга HTML?
2

window.onload, Захватить текущую метку времени черезNumber(new Date) в каждой из этих «точек последовательности» и вы можете получить первое впечатление о том, как долго страница должна отображаться без учета браузера.

0

WebWait работает в любом браузере.

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

Похожие вопросы