Frontpage OK for a Large Sites?

[jk3210]

Does anyone know if there is a particular size site by number of pages where FP starts to choke?

My site just went over 1,000 pages and, even though FP still does fine, I'm curious about how big of a site it can handle.

[lorax]

While I don't use FP anymore, I don't think you'll find there is a limit to the number of files you can work with.

[jimbeetle]

I was having a lot of publishing problems with a 1,500 page FP site until I switched from a slower WinNT server to a pretty fast *nix. It now pretty much blasts through a publishing and update session.

In FP you can tune performace to the size of the site -- but I *think* much has to do with memory when working on your local copy and your server setup when updating. Also the number of page includes, headers and footers, etc, it has to deal with when updating.

There *is* a limit someplace but at a 1,000 pages you're pretty safe for quite awhile.

Jim

[vitaplease]

I'm at aabout 1900 pages at the moment and publishing to an NT server takes too long. If you change address (on all pages) as I just did it choked whilst publishing, so I used a regular FTP download to publish.

My provider is moving me to a Win2000 server, ill see what that will mean publishing wise.

[pageoneresults]

Tuning Your Website [support.microsoft.com]

The above is not totally on topic but something you should consider having your host look into.

Server Timed Out Errors [support.microsoft.com]

Another issue to contend with on larger sites is a server timeout error. This is something your host also has control over.

I've never done anything in the 1,000 page range using FP and don't ever plan to. I've found that dynamic is the only way to go once you pass a certain threshold of pages within your site. In my case, I have that threshold set at about 150/200 pages if applicable. Some sites just need pure html pages sitting there because they don't fit in a dynamic environment. My motto is; let's see if we can make them fit! ;)

P.S. You also have the option of Saving Changed Pages Only when publishing. This will definitely bring the publishing time to a minimum.

[vitaplease]

thanks pageoneresults,

will look into that info!

[rogerd]

It seems like newer versions of FP are better, but one of the reasons I stopped using it was the tedious updating as sites got larger. The sites I was working with were well under 1K in page count, too.

One suggestion: Use server-side includes for all standard info like navbars, page heads, etc. This will let you change every page on the site by tweaking one small file - no super-slow shared border updates, or lengthy publishing sessions required. (Not a bad idea regardless of the HTML editor you use!)

If you search under FrontPage here, you'll find plenty of FP-bashing (and some defending). Assuming you can live with the other FP quirks/limitations, I think using SSI and avoiding almost all mass updates will make FP usable for a fairly large site.

[europeforvisitors]

I use FrontPage 2000 for a site with more than 3,500 pages. I've found that it's most efficient to convert major subdirectories into subwebs. (This is easy to do with the "Convert to Web" command, but you should be aware that you'll need to duplicate your shared borders, include files, etc. in the new subweb after the conversion.)

The biggest subweb in my site has maybe 2,000 pages, and I get a timeout error during the "processing updates" phase when I use FP's "Publish" command. This isn't a problem, since it's a spurious error and the site actually publishes just fine. The other annoyance with a really big subweb is how long I have to wait for an include file or border to save if I make a navbar change.

One of these days I'll probably split that 2,000-page subweb into two or three smaller subwebs for convenience, but I'm in no hurry. When I'm just adding and maintaining pages without changing the navigational scheme, I upload pages by ftp anyway (not out of necessity, but out of longtime habit).