Reducing load times of ASP.NET WebForms page with large tables
I have a WebForms page with a treeview on the left and grids on the right. When the user clicks a treeview node, the corresponding grid is populated using a SqlDataSource and then displayed. The whole thing's in a single UpdatePanel.
Here's my setup:
<asp:GridView runat="server" ID='LocationsRowGrid' AutoGenerateColumns="false" DataSourceID="SqlDataSource_LocationRow">
<Columns>
<asp:TemplateField HeaderText="Location">
<ItemTemplate>
<asp:DropDownList runat="server" ID="NAME_LCTN" OnDataBound="dropdown_DataBound"
DataTextField="NAME_TO_LCTN" DataValueField="NAME_TO_LCTN" DataSourceID="SqlDataSource_LocationNames">
</asp:DropDownList>
</ItemTemplate>
</asp:TemplateField>
<asp:TemplateField HeaderText="Move Time (HR)">
<ItemTemplate>
<asp:TextBox runat="server" ID="STD_MOVE_TME_AMNT" Text='<%# Bind("STD_MOVE_TME_AMNT") %>'></asp:TextBox>
</ItemTemplate>
</asp:TemplateField>
<asp:Bou开发者_高级运维ndField DataField="LAST_UPDATED_BY" HeaderText="Updated By" Visible="true" />
<asp:BoundField DataField="LAST_REV_DT" HeaderText="Revision Date" Visible="true" />
</Columns>
</asp:GridView>
There are other (larger) grids, but this is basically the template. The largest grid has about twelve columns, about six of which are templatefields with textboxes and one of which is a templatefield with a dropdown list. The dropdown is databound to another table, which has about 150 elements. The grid itself has about 100 entries.
This is slow. It seems like the problem might have to do with the rendering of the HTML - the server isn't taking TOO long to respond, but the browsers (Chrome and IE) are nearly falling over trying to render the result. My first (obvious) guess is that rendering 100 html selects, each with > 100 elements, is going to slow - especially when done all at once inside tables tags like ASP.NET will do.
Does this seem like a reasonable guess at the cause of the slowness?
For this project I am (currently) not allowed to use jQuery (or presumably any other javascript library) and must justify any and all javascript I use. Basically, other developers don't want to need any real understanding of javascript to be able to maintain this application when I'm done with it.
Given these constraints, is there anything I can do to reduce the size of the returned HTML and/or the render times in the browser? Thanks in advance.
My thought is reduce the amount of bound data on the initial page and institute paging. Unless this is a "report", the user does not need to see every row at one time.
Another possibility is you have the page set to also use viewstate for the grid. If so, you are consuming time in the bind to create the viewstate prior to rendering (at least in the default situation).
Beyond that, I agree with @n8wrl that you need to troubleshoot by isolating whether it truly is the rendering that is the issue. I would probably do this through tracing rather than turning things off, but you do have to make sure the problem is the rendering. Another control, like a repeater, may work, but I only see this as a benefit with something like CSS, which reduces the amount of tagged data to produce output.
Compressing the response stream in IIS can also speed things up. Rendering time will still be the same, but you will eliminate the time to send the HTML to the browser, which is at least part of your problem.
Several thoughts for you:
- 'Turn off' the rendering to see how much of the response time is in server-side querying. You can do this by commenting out DataSoource= statements.
- Browsers tend to wait until an entire table has made it before rendering any of it. You might try different layouts such that not everything is in a single table. Maybe a repeater where each item is a stand-alone table? Each can then render as the markup appears.
- You can start to get a lot more fancy with jQuery and AJAX to page your content. Instead of 100 rows maybe 10 rows with page 1, 2, 3... links?
精彩评论