First of all, I hope you have backed up your Pub file on a regular basis.
The larger the file, the more likely it is to go corrupt for one reason or
the other.
Secondly, it is very unclear about what you are doing when you say "each
link > placement ( now ) causes an increased lag time to process ( 14
seconds and > counting ); the more I create, the longer it takes to
process". But the bottom line is the larger the publication gets the longer
it will take to do anything with it.
One of the limitations of Publisher is when websites start getting large. It
is intended for relatively simple, static and small sites. Your site is a
good candidate for building with multiple Publisher files and that would
prevent the possibility of loosing the whole thing and all the processes
taking so long.
The concept is relatively simple. Each new section/story that you add to
your site, build it with a different Publisher file, and upload it to a
different subfolder on your directory. Say for example you split off the
section 'Eye Dew Weddings" that starts here:
http://www.thevoyageofkings.com/index_files/Page773.htm . Build this whole
section/story in a different Publisher publication. Create a folder on your
site called 'eyedew' or something similar at the same level as the index.htm
file and the index_files folder from your main web publication. Upload the
'story' web files to that folder, and then your link from the main site
would be
http://www.thevoyageofkings.com/eyedew/index.htm .
Just spend some time planning how you want to organize the directory and
then break up your site to a main site and build the other sections with
their own Pub files and published to their own folders.
Here is another resource for you to read that approaches it a bit different
than I do. I like using subfolders to organize my directory and using the
default 'index.htm' file name for each Pub file and each section, but this
is an alternative:
Building a web site with multiple Publisher web publication files:
http://msmvps.com/blogs/dbartosik/archive/2006/01/16/81264.aspx
DavidF