Another option might be to create a PDF version of this document for the download. It's not *ideal*, but it would certainly alleviate many of the transfer/rendering problems. You can still index the EAD on the back-end, and maybe even provide section-level access via AJAX and some back-end document calls, but if you want to make the whole thing available I wouldn't do it in HTML.
Is there any reason you need/want to keep it as a webpage?
On 2010-12-06, at 3:04 PM, Ken Irwin wrote:
> Would it make sense to break this up into several documents and add a search function? You could still have a giant, one-page (and thus easily-printable) option, but maybe that wouldn't be the default.
> The search feature I'm envisioning would just be a search of key words in the title of a box. A tag-cloud sort of thing might be a useful way of making some of the keywords visible too.
> -----Original Message-----
> From: Code for Libraries [mailto:[log in to unmask]] On Behalf Of Nathan Tallman
> Sent: Monday, December 06, 2010 2:49 PM
> To: [log in to unmask]
> Subject: [CODE4LIB] HTML Load Time
> Hi Cod4Libers,
> I've got a LARGE finding aid that was generated from EAD. It's over 5 MB
> and has caused even Notepad++ and Dreamweaver to crash. My main concern is
> client-side load time. The collection is our most heavily used and the
> finding aid will see a lot of traffic. I'm fairly adept with HTML, but I
> can't think of anything. Does anyone have any tricks or tips to decrease
> the load time? The finding aid can be viewed at <
> Nathan Tallman
> Associate Archivist
> American Jewish Archives