I suggest that you arrange things so that, even if some or most of your content actually comes from “static files,” your CGI::Application is consistently “how it happens.”

In other words, you use mod_rewrite, which pretty much every shared-hosting client will support. You send ordinary static stuff like CSS and image-directories directly to the files, which really are static, but the rest of it ... all the rest of it ... you direct to your application. Even if the only thing that the application actually does is to determine the location of a straight-HTML file, grab it up and serve it (perhaps through a suitable template...), the application does it.

The URI's presented by the web-user have no direct or obvious relation to the actual files from which the content may come. Those files are accessible to the Perl script, but not directly to Apache.

What this does for you is to eliminate Apache's need to make any meaningful distinction, with respect to “actual content.” As far as Apache is concerned, it's either an image, or a stylesheet, or ... something that should be handled by Perl. Apache hands the request-URI to Perl, and Perl serves up the content. So, in the end there is only one way for “content” to be served. Not two.

These days, I'm running quite a few sites in which most of the content is static. Dynamic content is the rare exception, not the rule. Yet it is impossible for you, the web-site user, to know the difference. Apache certainly doesn't know the difference.