Есть ли эмпирическое правило о том, сколько заполнителей можно разместить на веб-странице?

Question

Использование aspx и C# 3.5, vs2008.

Есть ли эмпирическое правило о том, сколько заполнителей может быть помещено на веб-страницу, прежде чем производительность начнет ухудшаться?

Любые другие проблемы при использовании большого количества заполнителей?

Я динамически подставлять элементы управления (текстовые поля, флажки, выражение валидаторов, и кнопки на моей странице.

Answer 1

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

цитирую г-н Кнут:.!

Преждевременная оптимизация является корнем всех зол

Answer 2

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

Answer 3

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

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

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

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

1.) Посмотрите на окончательный визуализированный размер HTML. Вообще говоря, я предпочитаю, чтобы мои общедоступные HTML-страницы под 100 КБ каждый, а домашняя страница - до 20 КБ, когда это возможно. Очевидно, что еще не конец света сделать HTML-страницу больше, чем это (многие популярные сайты делают). Но многое из этого я бы, по крайней мере, подумал о том, чтобы разделить его на несколько страниц. Высокоскоростные соединения могут распространяться сегодня, но пользователи так же нетерпеливы, как и раньше, поэтому быстро создайте сайт. ;)

2.) Всегда есть вопрос о масштабируемости. Чтобы проверить это, вы можете проверить Microsoft's Web Application Stress Tool, чтобы попытаться смоделировать ситуацию пиковой нагрузки. Затем взгляните на такие вещи, как процессор, память и использование полосы пропускания, чтобы узнать, не наносит ли он большой ущерб на сервере. Опять же, если это слишком большая загрузка, вы можете рассмотреть возможность разделения страницы.