优化您的 Web 站点 接手一个可维护的 Web 站点并将其打磨、抛光、流线化（3）

look_w

服务器端包含：决定性因素 假设您从 HTML 提取出 CSS，将 JavaScript 放入外部文件中，您甚至设法将所有的事件处理程序任务在 onLoad 事件中合并为页面的 body 标记上的单个方法。您已经完成了页面的编程部分，对吗？不幸的是，尚未完成。您仍然要担心一件事：服务器端包含（通常称为 SSI 或 SSIs）。它们通常如下所示：

1	<!--#config timefmt="%A %B %d, %Y" -->Today is <!--#echo var="DATE_LOCAL" -->

这将以指定格式打印出当天的日期。
服务器端包含在目前似乎是一次性事物；您可以大量使用，也可能完全不用。换句话说，您将发现到处存在这些包含的页面（用于时间戳、上次修改日期、计数器、页眉、页脚等等……好了，这个列表太长了）或者您在页面中根本 找不到服务器包含。事实上，您将很少发现一个站点使用 1 到 20 个 SSI；大多数站点或者完全避免使用 SSI（一个都不会用），或者疯狂使用 SSI。
SSI 是坏还是邪恶？ SSI 根本没有错。大多数程序员目前偏爱较新的脚本语言，比如 PHP、JSP 或 ASP（取决于所选的供应商或技术），但 SSI 通常是一种无需太多工作就可以在 Web 页面中添加少许功能的简单方法。
但是，SSI 在被过度使用时将会变成一个问题。例如，使用标准页脚时，可能具有一个颜色栏，一组联系链接和一个版权信息。可以将此页脚包括在站点的每个页面底部，如下所示：

1	<!--#include virtual="/footer.html" -->

但这相当方便，所以您也可以构造一个通用的页眉，并一开始就将其包括在文档中。导航通常也是通用的，所以 SSI 也可能适用。（虽然导航将基于当前页面有稍微的改变，但是带有导航链接的包含页面也可以使用一些 SSI 来实现一些显示逻辑。）而且您可能想列出最新的几篇博客，或者最近更新的几个页面，或者可能只运行另一个脚本来加载 cookie 并提供个性化问候。SSI 均适用。of this.
问题在于每个步骤都会引发开销。您跟踪越来越多的小文件（这还没什么）但还要构建一组未归档的假设。每个页面必须将页眉和页脚包含在特定目录中（或对 SSI 包含进行更改以指向包含文件所在的正确目录）。它很快就变成了一个重要角色。而且，可能最重要的是，您将 SSI 作为脚本语言对待以构建动态页面。这不是 SSI 最擅长的；相反，SSI 擅长一些非常细微的功能。
缩减 SSI 如果试图让站点变得更好、（更）可维护、对于设计人员和开发人员更友好，则可以考虑尽可能合理地提取出尽可能多的 SSI。如果需要在当前日期中使用一个，那就没什么。如果您的页面仅仅是尖括号注释（<!-- 和-->）之间的 SSI 包含和逻辑的组合，则可以考虑简化您的站点，或转向使用功能完全的 Web 脚本语言，比如 JSP 或 PHP。
此外，如果您已经 在使用 PHP 或 ASP.NET 或 JSP，那么您应该将页面中所有的 SSI 都提取出来。一旦您已经投入（在时间和专业技术上）到一个脚本语言中，那么就坚持下来。您将具有相同数量的开销，但您只需使用较少的技术。HTML、CSS、JavaScript 和您的脚本语言已经远远足够了，无需将 SSI 添加到此混合物中。
组织站点的文件 如果已经跟上来，尤其是您已经具有一个在页面中组合了 HTML、CSS 和 JavaScript 的站点，您就已经解决了许多问题 —— 并潜在地创造了一些新问题。一旦开始将结构（HTML）从显示（CSS）、操作和行为（JavaScript）分离出来，您就具有许多散播在各处的单独文件（HTML、CSS 和 JavaScript）。
当然，还有大多数 Web 站点具有的正常文件都包含：10 个、100 个甚至 500 个不同页面的 HTML 页面，潜在的页眉和页脚导航支持文件，图像，文本文件，更多图像（相信您已经明白了）。而且，将一个文件向下加载三个目录和向上加载一个目录不会耗费太多时间，查找 此文件却需要很多时间。再一次重申，组织是关键，如果您想让站点长期保留（也就是说，在漫长的周末睡上两次，并忘记一切），花一些时间对其进行组织是十分关键的。
按种类和类型全局组织文件最常用的布局选项（除了仅仅将一切统统塞进一个目录之外）是从站点的根目录开始，按类型组织所有文件。例如，您已经具有一个 images/ 目录，一个 css/ 目录，可能还有一个 js/ 或 scripts/ 目录，然后所有的 HTML 文件都在根目录下。因此，您的所有文档都具有类似 images/header.gif 和css/default.css 的路径。
这是重要的第一步，因为您立即知道图像在哪里 —— 在自己的目录中。而且您的 CSS 也在自己的目录中。脚本呢？完全一样。对于您或新的设计人员和程序员来说，组织事情十分容易，而且完全是自文档化的。无需解释或冗长的文档就能够弄明白一切。
如果您按照十分常见的实践将 HTML 文件存储在子目录中，则还有另一个小小的优点。假设您已经使用 blogs/ 目录存放所有的 HTML 博客帖子，使用 music/ 目录存放对 CD 和音乐会的所有评论。如果将所有的图像存放在站点根目录下的 images/ 目录中，则在 img 标记中不必使用相对路径 src="local-image.jpg"，而是使用 src="/images/image-name.jpg"。
更重要的是，在您开始包含库模板中的页眉和页脚时，您已经在 blogs/ 目录中获得了一个文件来包含站点根目录（或者，甚至更好的是 templates/ 目录）中的页脚，您必须导航令人混淆的路径结构。所有路径都从站点根目录（/）开始并前进。这避免了跟踪您所在的目录，而且甚至更好的是，避免了类似 src="../../images/logo.png" 的冗长路径。
但是，此方法的缺点在于您的所有图像都位于一个位置；您的所有脚本位于一个位置；您的所有 CSS 位于一个位置。是的，这也是优点，但单个位置本质上意味着您可能具有名称冲突。如果您将full-moon.jpg 存储在 /images/ 中以配合您令人深思的有关纽约的午夜博客帖子，然后在六个月之后，您在一个兄弟晚会上捕捉到您小舅子令人尴尬的一瞬，于是将full-moon.jpg 存储在 /images/ 中，那时会发生什么？好了，就这样说吧，如果有人看到您写的有关曼哈顿美妙一夜的博客帖子时，他将会惊异于所看到的画面。
这是名称冲突 的典型情况：两个文件在同一目录中尝试共享一个名称。如果按种类组织一切，您将必须切记不要用具有相同名称的新文件覆盖旧文件。否则，您将发生冲突问题，没人想这样。
按站点分组的嵌套组织 第二种方法比全局分类稍微好一些，是利用分类的总体概念并将其递归应用。假设您的站点具有四个部分：产品、文档、支持和 FAQ。您已经在服务器的根目录下创建了四个目录，可能是 products/、docs/、support/ 和faq/。然后，您要将分类方法应用于其中每个 目录。
因此在 products/ 中，您将具有 images/ 目录、css/ 目录和 scripts/ 目录等等。产品的所有 CSS、JavaScript、图像和资源将位于此子目录中。本质上，您已经创建了产品的迷你站点。然后，同样的规则适用于其他三个目录。每个目录都将具有图像和脚本等等，所有内容都存储在此子站点的目录中。
在组织上，这比较容易处理。如果您在操作产品页面，则所有资源都在此目录中。而且可能更重要的是，其他页面的所有资源都不 在产品迷你站点中。所以您只需处理少数文件，其中所有文件都与您操作的内容相关。
最后，这使得名称冲突更容易避免。您将处理更小的文件集合，使用相同名称的几率将减少。这并不意味着它们不会发生，但因为文件比较少，所以甚至可以在替换或覆盖具有相同名称的文件之前手动进行检查。
当然，这种方法的缺点在于您很容易重复一些资源。如果所有的 “迷你站点” 上的所有页面都使用相同的页眉、页脚或徽标怎么办？突然，迷你站点崩溃了，或者至少变得复杂了。当然，答案并不深奥；相当的显而易见。
使用全局和区段分组之间的混合 实践证明，为站点组合一个合理的物理布局，您实际上需要两个级别的分类。首先，您需要弄清楚站点中的一切全局 内容：跨越两个或多个迷你站点。所以如果您已经具有整个站点的页脚，或一个通用的徽标，或所有页面使用的 CSS 样式表，这些都是全局资源。它们不应该嵌套在子目录中，因为您的所有页面都需要它们。
然后，一旦您弄清楚全局资源之后，就将其放置在 Web 服务器根目录下的分类子目录中。所以，您已经将全局样式表放置在 /css/ 中，并将所有页面需要的脚本放置在/scripts/ 中。然后，应用如前所述的迷你方法：分离到子目录中，并将只有特定迷你站点使用的资源放到相关子目录中（仍然是 images/ 或scripts/ 或任何适当的位置）。
如果采用此方法（而且它是 Web 专家最常使用的方法），您实际获得了两个世界的最高境界。您通过隔离迷你站点减少了一个位置的文件数，并合理地避免了名称冲突。但您还降低了资源的重复，所以共享文件的迷你站点只使用此文件一次。
但是，您必须做出一个选择：是否、何时引用全局文件，使用 “../” 表示法（比如../images/logo.jpg），或绝对路径表示法（比如/images/logo.jpg）。您最好避免所有的 ../ 类型（这将迅速转化为 ../../ 甚至 ../../other-section/images）。如果您已经使用了此混合法，那么您将在类似 images/blog-header.gif 的路径中获得特定于本地迷你站点的图像。这十分便于查看和欣赏，而且仍然尽量保持自文档化。而且，结果里外都是易于理解的 HTML 页面。这对于您、您的团队成员以及使用您页面的任何人来说都是一件好事。
避免大桶方法 不管使用什么方法，实际上只有一个方法是明显错误的：大桶方法，即将一切抛到一个目录中。您通常可以通过 public_html 目录标识这些设置，此目录通常由启动站点或 GUI 工具使用。不管是启动站点还是 GUI 工具都需要您这样组织内容（也就是说，不 组织内容），对于一些人来说，通常更简单的是将一切都保留为 GUI 编辑器或 FTP 工具所布置的那样。
此方法最明显的问题是，与页面 数相比，系统中的文件数通常按指数级增长。所以一个页面通常引用两个或三个其他页面，五个或十个图像，可能一个 CSS 样式表和一些 JavaScript —— 甚至是类似通用样式表或 JavaScript 文件的共享资源，事情迅速变得不可控制，而且，事实上，您将费大力气去逐个组织您的 HTML 页面，那么为什么不将相同的原则应用于站点的物理布局呢？
在按类别全局分组一切那一节中也有相同的问题：名称冲突。您将图像放入具有数百个其他图像（更不用说数百个所有 类型的文件）的目录中，您将不得不认真思虑一番了。当然，您可以只执行一个简单的 ls 或dir，但大多数不花时间组织其站点物理布局的人也不会花时间来采用这样的预防步骤。结果呢？覆盖的文件、图像（或CSS 或 JavaScript）被神秘地 “更改”，页面乱七八糟地分散在站点中与您预期完全不同的部分中。