There is no magic way to make a 2.5M file load quickly in a browser --
let alone be actually useable once in a browser window. (What human is
going to read 40 or 50 or 100 pages all at once in a browser window?).
2.5M is just too big for a web page. You're going to have to split it up.
On 12/6/2010 3:41 PM, Nathan Tallman wrote:
> Ethan: All of our online finding aids are static HTML files, with a handful
> generated from EAD 1.0 files. I'm working towards getting all our finding
> aids in EAD and will probably use XTF to publish them, but that's a ways off
> at this point. In regards to this example (EAD v. 2002), yes, the<dsc> is
> causing the file to be so large. The collection is over 1200 boxes and the
> description is at the folder level. There's not much external content to
> point to, so I'm not sure if XInclude or EAD pointers will help. I'll look
> into using AJAX.
> Dave and Brian: I've been trying to avoid breaking the page into multiple
> files, but it may get to that point. If I split the page into say three
> parts and then combined them on one page using the include function of PHP,
> would I still have to same problem? I'll look into gzip too.
> There's another live version of this finding aid that's been up for years<
> http://americanjewisharchives.org/aja/WJC/wjc-main.htm>. It's generated
> from an EAD 1.0 file and uses (gasp!) frames. You can probably tell by
> looking at it why I would like to replace it. It was encoded a bit wonky
> too, with separate<dsc> section for each series. That's been corrected in
> the new EAD v. 2002 file.
> Thanks for your replies!
> On Mon, Dec 6, 2010 at 3:02 PM, Ethan Gruber<[log in to unmask]> wrote:
>> Hi Nathan,
>> A 5 MB EAD XML file will result in an HTML file of at least that size, so
>> certainly 5 MB will result in a long load time for people on a slower DSL
>> connection, or God forbid, dialup (does dialup still exist?).
>> A few questions first:
>> Are your finding aids transformed into HTML files that are served up
>> statically or generated dynamically?
>> Is it your list of components (<dsc>) that is so large?
>> You may be able to find your way around the filesize issue using Ajax to
>> dynamically load content only when the user asks for it. There may also be
>> an alternate way of encoding your finding aid in order to reduce its
>> filesize, either by using XInclude or EAD pointers to external content.
>> XIncludes in conjunction with Ajax calls can alleviate problems in
>> in the public interface as well as make it possible to view the XML files
>> Notepad/Dreamweaver again.
>> On Mon, Dec 6, 2010 at 2:49 PM, Nathan Tallman<[log in to unmask]> wrote:
>>> 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
>>> 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