Если изображение, которое вы разместили, является репрезентативным для всей вашей проблемы, я думаю, что у вас нет проблем, потому что поврежден только левый столбец, и, насколько я вижу, этот столбец показывает только эквидистантный список чисел с шагом 0.5
. Если вам это нужно в качестве значения x диаграммы, вы можете просто создать ее отдельно и импортировать только данные правого столбца.
Каждый раз, когда возможное применение Средства управления HTML. Средства управления HTML. Они легче, так как не имеют объектов серверной стороны, если Вы не указываете runat="server"
атрибут.
Я не знаю, как удалить клиентское идентификационное чрезмерное увеличение размера, но некоторые общие советы для того, чтобы сделать Ваши страницы меньшими были бы:
Для уменьшения веса страниц ASP.NET можно также переопределить свойство PageStatePersister (класса Page) с SessionPageStatePersister. Посмотрите пример здесь. Тем путем Состояние отображения будет сохранено в объекте Сессии на стороне сервера, таким образом уменьшая размер страницы HTML на стороне клиента.
Особенно в повторителях, ListViews и GridViews, называют Ваши средства управления чем-то коротким.
Это должно быть очевидно Контекстом (Список продуктов)
Если у Вас есть только один HyperLink в повторителе, назовите его hl. Вы не должны называть эти средства управления HyperLinkProduct.
<asp:Repeater id="rptProducts" runat="server">
<ItemTemplate>
<asp:HyperLink id="hl" runat="server" NavigateUrl='<%# Eval("URL") %>'>
<%# Eval("Name") %>
</asp:HyperLink>
<asp:Image id="img" runat="server" ImageUrl='<%# Eval("ImageUrl") %>' />
</ItemTemplate>
</asp:Repeater>
Это представит что-то как:
<a id="ctl00_rptProducts_ctrl0_hl" href="/products.aspx?id=5">
Product Name
</a>
<img id="ctl00_rptProducts_ctrl0_img" src="images/5.png"/>
Умножьте те идентификационные названия на 100, и Ваши идентификаторы начинают поднимать намного больше пространства при использовании долгих описательных имен. В Повторителях короткие идентификаторы должны быть достаточно четкими, если Ваш Повторитель хорошо назван.
У водяной черепахи есть некоторые большие предложения, но они являются довольно идеалистическими. Если Вы ищете более применимые решения своей текущей ситуации, проверяете адаптеры управления.
CSS Дружественные адаптеры сделает большую работу для Вас для преобразования средств управления ASP.NET из большого ужасного, длинного идентификатора, названного таблицами в более краткие отделения с более короткими именами.
Я использовал их в прошлом, и они могут действительно иметь огромное значение. Кроме этого, выключите состояние отображения на любом управлении, для которого не нужно оно. Соответствуйте надлежащему CSS/HTML, и это будет иметь другое значительное значение.
Всего наилучшего
Используя CSS Спрайты могут ускорить Вашу страницу путем сокращения количества запросов. Вот некоторые статьи Я нашел.
В Вашем случае использования маркировки удостоверьтесь, что действительно необходимо использовать маркировку (который генерирует текст в a <span>
тег. Вы могли использовать a Literal
вместо этого.
Набор EnableViewState="False"
на средствах управления, для которых не нужен он (или на всей странице/веб-сайте)
Если Вы пробуете, изменяют неясные идентификаторы, сгенерированные ASP.NET, нет очень, можно сделать там.
Используйте html/css, чтобы разработать Ваши страницы, избежать таблиц для расположения, когда создание маркировки указывает идентификатор, короче это, лучше.
Выключение состояния отображения, как Вы упоминаете, хорошо. Также я заметил, что управление деревом ASP.NET генерирует очень большую сумму HTML (если у Вас есть достаточное количество узлов). Я закончил тем, что писал свое собственное древовидное управление, которое генерирует 1/4 HTML стандартного древовидного управления. Таким образом, Вы могли искать средства управления как этот, который особенно плох, и пишет Ваше собственное управление.
Я предполагаю, отчаянно пытались ли Вы делать это, не переоборудуя Ваши страницы (и ни одна из других разумных идей не работала ;)), Вы могли сделать это:
Запишите http модуль, который анализирует и извлекает идентификаторы с короче, распознаваемые уникальные идентификаторы на лету, когда страница отправляется клиенту, и сохраните их в хеш-таблице области действия приложения. Затем в обратной поездке выполняют обратный шаг для входящих данных.
По крайней мере, это - то, что я попробовал бы. Я не уверен, как приятно это играло бы с определенным HTML и/или конструкциями JavaScript, но я думаю, что это могло быть сделано. Я подозреваю, что это была бы боль в торце, чтобы сделать, особенно если бы более короткие уникальные идентификаторы, оказалось, конфликтовали с какими-либо legitmate незначениями идентификаторов.
Править: Просто помнивший. Необходимо было бы обработать ViewState также... (который должен будет декодироваться, фиксироваться и повторно кодироваться. Походит на большую проблему :) Но с другой стороны, если Вы собираетесь перейти к той проблеме, можно сжать состояние отображения намного лучше путем переопределения загрузить/сохранить методов состояния отображения... Я сократил некоторые огромные страницы (200K HTML) вниз к приблизительно 30K использование что метод несколько лет назад. На самом деле использования пользовательского сжатия на ViewState может часто быть достаточно для сокращения размера страницы чрезвычайно.