How can I make my web page load faster?

[sudhakar]

Hi...,

I would like to know is it advantageous to use client
side XSLT compared to server side xslt expecially when the
xml file is big enough (say 200KB) and the transformation
is complex.
I haven't tried server side xslt since there is not much
data to cache on the server.

The principal problem of ours is to render a large web
page (using html tables) with dynamic data (data is
usually different every time the page loads) in a minimum
possible time.

We are using MSXML 4.0 with ASP and ADO, SQL2K on Win2K
server. We find that the server side processing takes less
than a second but it seems to be the bandwidth (though our
clients use DSL conection speeds) that is making our web
page load slower.

Based on my experience with this topic I noted the
following:
Our previous implementation using plain asp, ado and html
(no xml at all) generated the html file (size: 160KB) for
the same data and html. It took about 6 sec to render on
client browser (IE6).

With client side xslt I noted the following:
xsl file size: 30KB
xml file size: 150KB (for the same data)
Time to render on the IE6 browser on client computer took
about 8 secs or more. All this despite our efforts to cut
down the size of the xml file by minimizing the no. of
tags.

Based on this and further investigation I concluded that
this delay with xml is happening because of bandwidth +
slow client side xslt.

I would like to know if there is any way to expedite our
web page rendering on client?

Any help is appreciated.

Cheers,

Sudhakar

[Charlie]

I'll handle this one boys. Something that I might be able
to give some insight on and feel like I know what I'm
talking about.

Some options I could think of:

Give your clients an option to parse your XML and XSL with
MSXML 4 (they say it parses faster than previous versions)
and they can bookmark to it.

Use DIVS instead of tables in your XSLT because they use
less tags...maybe not...bad idea?

Fixed-size tables[1] render faster than nonfixed tables.
For example in your CSS file add "table{table-
layout:fixed}" and in your XSLT use the <col/> tag.
Depending on your table layout you can give your <col> or
<td> a certain width in your CSS file.

Now we get really crazy.

In your xml you can use single letters to form your XML
tags. Like "<a>".

You could run an optical cable strait from your computer
to your client's computers.

From Charlie
(the xslt NOVICE - not newbie...stop making up/using words
in which there are already words for).

[1]
http://msdn.microsoft.com/workshop/author/perf/perftips.asp
?frame=true#Use_Fixed-Size_Tables

>.
>

[sudhakar]

Hi...,

Thanks for the quick response.
We are already making sure that we use MSXML4 on client
browsers.

I have not tried the DIVs yet... but essentially my web
page consists of a long HTML table with atleast 1500
cells - each with DHTML events. So I think the DIV
approach may not work...

I can try the fixed layout table approach and tags with
less no. of chars and see if it really helps...

Also I am interested in any tips and ideas about how to
process the XML-XSLT on client side to HTML faster...

Any help appreciated...,

Cheers,

Sudhakar

>.
>

[DWilliams]

sudhakar,

Seems that your answer might be related to controlling/limiting the amount
of data displayed on each page and not necessarily worrying with the data
storage and rendering technique. Have you considered trying implement a
server-side paging script? Here is an article on how to do just that using
an SQL stored procedure...

http://www.aspfaqs.com/webtech/062899-1.shtml

HTH,
DWilliams

"sudhakar" <samba...@mailcity.com> wrote in message
news:34ba01c24568$e5a1d9a0$a4e62ecf@tkmsftngxa06...

[Marrow]

Hi,

>With client side xslt I noted the following:
>xsl file size: 30KB
>xml file size: 150KB (for the same data)
>Time to render on the IE6 browser on client computer took
>about 8 secs or more. All this despite our efforts to cut
>down the size of the xml file by minimizing the no. of
>tags.

Is the 8 secs for the rendering alone - or for the time of transformation +
rendering. You need to differentiate between the time taken to transform and
the time taken to render - as the remedies for these will be different although
interrelated.

If a large proportion of that time is being taken up with the transformation -
then I would suggest that it is the XSLT that need optimizing. Perhaps a look
at the XSLT and a sample of the input XML might establish whether there is any
scope in the XSLT code for peformance tweaking.

Cheers
Marrow

sudhakar wrote in message <34ba01c24568$e5a1d9a0$a4e62ecf@tkmsftngxa06>...

[msnews.microsoft.com]

I ran into the same problem. I wrote a XSLT utility to filter, sort and
group XML records on the client-side. It takes an average of 2 seconds to
process every 100 records. For a report that has 2000 records, it takes a
very long time to transform/render the report.

But I think a solution to this is to provide two modes for your report, one
for online viewing and the other for printing. For the online viewing mode,
maybe you can render only the first 100 records on the first run, so your
users can start viewing the results. While they are using the results, your
client-side scripts launches a second run of transformation and rendering to
process the remaining records. That way, your client experiences very little
delay when they open up the report. Another alternative to this is to use
record paging, where every page of the report only displays 20 or 30
records. Every time the user clicks "Next" or "Previous", you invoke your
client-side scripts to process 20 or 30 records. This will be fast too.

The other mode, the printing mode (or printer-friendly mode), can render the
entire report using ASP on the server side, without even the need to use
XSLT. The resulting HTML page (which includes all the records) can then be
streamed down to the client. Because the user only needs to print the report
out, there is no need to use client-side transformation to provide extra
features. You can have some reports default to the vewing mode, while others
default to the printing mode, depending on how they are most frequently
accessed by the users.

Also, most of the client-side transformation uses this javascript scheme:

document.all.myDIVcontainer.innerHTML = oXML.transformNode(oXSLT);

In addition to the overhead of XSLT transformation, the time required for
the browser to insert a large of amount of HTML tages and text into the
DIVcontainer can be expensive too. I am still wondering if there is a less
expensive way to insert it into an existing page.

Henry

"sudhakar" <samba...@mailcity.com> wrote in message
news:34ba01c24568$e5a1d9a0$a4e62ecf@tkmsftngxa06...

[Marrow]

Henry,

>It takes an average of 2 seconds to
>process every 100 records. For a report that has 2000 records, it takes a
>very long time to transform/render the report.

2 seconds to transform 100 'records' (elements?) seems an inordinate amount of
time - perhaps there are some things in your XSLT that could be done differently
that would improve this dramatically. A look at your XSLT code and sample XML
input would give a better idea if there are things in the XSLT that might be
tweaked.

Cheers
Marrow

msnews.microsoft.com wrote in message <#EuYZjfRCHA.4260@tkmsftngp09>...

[msnews.microsoft.com]

My XSLT templates are not 100% optimized. There are several places that can
be made to run faster. I use the same templates for all reports that need
the filtering, sorting and grouping features. But the point is, client-side
transformation is time-consuming. If the server is not busy, I get a better
performance by sending another request to the server than trying to filter
or sort records on the client-side, especially on the intranet.

Henry

"Marrow" <marrow-NO-@-SPAM-marrowsoft.com> wrote in message
news:vyt79.972$yj4....@newsfep3-gui.server.ntli.net...

[jam...@gmail.com]

This is another use for XML
https://www.youtube.com/watch?v=JZF25v4mrEs