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!
Nathan
On Mon, Dec 6, 2010 at 3:02 PM, Ethan Gruber<[email protected]> 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
rendering
in the public interface as well as make it possible to view the XML files
in
Notepad/Dreamweaver again.
Ethan
On Mon, Dec 6, 2010 at 2:49 PM, Nathan Tallman<[email protected]> 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
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<
http://www.americanjewisharchives.com/aja/FindingAids/ms0361.html>.
Thanks,
Nathan Tallman
Associate Archivist
American Jewish Archives
