本节书摘来自华章社区《Web前端工程师修炼之道（原书第4版）》一书中的移动专用网站，作者Jennifer Niederst Robbins，更多章节内容可以访问云栖社区“华章社区”公众号查看

移动专用网站
自适应网站的替代方案，是建立一个完全独立的网站、一个单独的网址来为移动设备提供服务。移动网站的网址常用的前缀是m.或mobile。对于某些类型的网站，如果你知道手机用户和台式电脑用户具有不同的行为模式，建立移动专用网站是最好的解决办法。在移动专用网站上，最常用的功能需要在第一个屏幕上突出显示，而台式电脑网站上的一些额外功能（如促销）就被移除了。（这也会使你思考这些额外功能究竟为台式电脑网站提供了什么样的价值。）
图3-4对比了2012年中期Walgreen公司主网站和移动网站。你可以看到移动网站为手机用户提供了一个更精简的选项集。
移动专用网站为智能手机上的用户将复杂的任务简便化。Luke Wroblewski在他的文章中“为什么分别建立移动和桌面网页？”（www.lukew.com/ff/entry.asp?1390）中详细地说明了他服务的Bagcheck选择建立一个单独的网站的原因。我建议你读一读。
这里的要点是，自适应Web设计并不是一个普遍的解决方案。对于功能主要是提供文本内容的网站来说，一点点布局的调整就可能为所有设备带来良好的阅读体验。对于其他网站和Web应用来说，可能就要优先考虑提供完全不同的体验。
移动专用网站的缺点是，它需要两倍以上的工作量。它需要额外的内容规划、模板设计、生产时间和日常维护。但是，如果这样做能给用户提供真正需要的功能，当然是非常值得投资的。

图3-4：移动专用网站与主网站的对比

进一步阅读
在具有了编码的经验后，在第18章中会详细讨论自适应Web设计。为了进一步对你进行自适应设计教育，我推荐以下书目：
Ethan Marcott的书《Responsive Web Design》（A Book Apart出版）是初级网页设计的必读书。这是一本小书，是学习自适应Web设计，以及如何自己尝试的完美起点。
Lyza Danger Gardner和Jason Grigsby所著（O扲eilly Media出版）的《Head First Mobile Web》。这部书详细阐述了自适应Web设计，并讲解了脚本和服务端检测的技术。这本书需要你熟悉一些CSS和JavaScript，而且读来也是非常有趣的。
可访问性——所有用户，一个网站
我们已经讲过当今使用的很多浏览器，但是迄今为止，我们讲的只是鼠标和指尖的视觉控制，但是很重要的是，要记住人们往往用不同的方式来访问Web，如屏幕阅读器、盲文输出、放大器、控制杆、脚踏板等。Web设计师一定要采用某种方式来使信息展示出来，不管用户的能力如何、访问Web的设备如何。换句话说，Web设计师的设计必须是可访问的。
当打算为残疾用户，如视力低下或者移动不便的人设计网页时，会采用一些技术和策略，这些技术和策略对其他用户（如手持设备用户，或者采用缓慢调制解调器连接的，以及禁用图片和JavaScript传统的浏览器的用户）来说，会带来低于最佳效果的浏览体验。可访问的站点被搜索引擎（如Google）收录的效率也更高。多下些功夫，使得你的站点便于访问将是非常值得的。
有4个大类的残疾会影响到人们与自己的电脑和信息互动，它们分别是：
视力受损型。视力低下或失明的人可是使用辅助装置，如屏幕阅读器、盲文显示器或者屏幕放大器来从屏幕上获得内容。他们也可以简单地使用浏览器中的文本变焦功能，以方便阅读文本。
运动不便型。如果用户的手不便移动或者根本无法移动，可以使用特殊的装置，如特制的鼠标和键盘、脚踏板或者操纵杆来浏览网页，并输入信息。
听觉受损型。用户听力微弱或者失聪会错过多媒体的音频信息，因此，有必要提供一些替代的方式，如视频的文字记录或者视频字幕。
认知障碍型。网页设计的简洁明了对于在记忆力、理解力、解决问题的能力和注意力上有缺陷的用户来说是非常有帮助的，而且对任何浏览你的网站的用户都是有帮助的。
W3C从Web的可访问性开始来探讨如何使Web为每个人所使用。WAI站点（www.w3.org/WAI）对学习Web的可访问性来说是一个很好的起点。其中由WAI发布的一个用来帮助开发者创建可访问的站点的文件是网络无障碍指南（WCAG和WCAG2.0），你可以通过访问www.w3.org/WAI/intro/wcag.php.来阅读。美国*用WCAG的Priority 1 points来作为可访问指导原则508节的基础（见侧栏“*可访问性需求：508节”）。所有的站点都受益于此项指导原则，如果你正在设计一个*网站，遵循这项原则是必需的要求。
W3C的另一个贡献是WAI-ARIA（可访问的富Internet应用程序）规约，它提出了Web应用程序（包括动态内容生成、脚本、适用于辅助设备的界面元素）的可访问性。ARIA建议书定义了一系列的内容和部件，对这些内容和部件可以使用role属性。role包含菜单、进度条、滑动条、定时器、工具箱等，并在语义上添加了更深层的特性。想进一步了解role，可以访问：www.w3.org/TR/wai-aria/roles#role_definitions。
*可访问性需求：508节
如果你要为联邦*创建一个网站，你就必须遵守508节的指导方针，以确保电子信息和技术对于残障人士也是可用的。*和其他公众机构也需要遵守这些准则。
以下准则是从www.section508.gov的508节中摘出来的，它提供了一个关于基本可访问性的很好的清单。

1. 每一项非文本元素必须提供相应的等效文本内容（例如，通过使用"alt"、"longdesc"，或在元素内使用）。
2. 等效内容必须在各种表现层上内容一致。
3. 网页设计时，所有通过色彩表达的信息，必须同时以非色彩方法表达，如上下文或置标符号。
4. 文档必须在没有相关样式表时也可正常阅读。
5. 对于行与列的头有两层以上逻辑的数据表格。数据单元格与头单元格应使用置标语言标出。
6. 对于具有两个以上含有行或列标题的逻辑层的数据表单来说，标记可以用于相关的数据单元格和标题单元格。
7. 页面设计中，应避免出现屏幕闪烁频率高于2Hz且低于55Hz的情况。
8. 当页面采用脚本语言显示内容或生成界面元素时，所传递的功能与信息必须可以被辅助技术/工具阅读并识别。
9. 当网页要求应用、插件或其他应用程序在客户端表现页面内容时，该页面必须提供相应链接指向该插件或应用。该插件或应用必须符合§1194.21中(a)到(l)的条款。
10. 当电子表单设计成在线填写时，该表单必须允许用户可使用辅助技术/工具来访问相关信息、字段元素，以及为完成表单的填写与提交而设计的功能，包括各种说明与提示。
11. 必须提供方法，以允许用户跳过重复的导航链接。
12. 当对用户的响应有时间要求时，该用户应该得到事先提醒，并有足够的时间来要求更多的时间宽限。
    进一步阅读

下列资源对刚开始学习Web可访问性是很有用的：
Web可访问性倡议（WAI）, www.w3.org/WAI 。
WebAIM：牢记Web可访问性，www.webaim.org。
Joshue O Connor 所著（Professional Apress，2012年出版）的《Pro HTML 5 Accessibility》。
Wendy Chisholm 和 Matt May所著（O扲eilly，2008年出版）《Universal Design for Web Applications: Web Applications that Reach Everyone》。
连接速度的要求（站点性能）
虽然使用慢速拨号方式上网的用户不断减少（写作本书时，美国只有5%~10%这样的用户），使用手机访问Web的用户比例明显增加，并将最终超过桌面用户。如果你有一部智能手机，那么你就知道使用蜂窝数据连接访问网页时，漫长的等待是多么令人沮丧。
但是不管用户如何访问你的网站，网站的性能都是至关重要的。Google在2009（注1）年的一项研究表明，搜索时间增加100~400ms时，搜索会减少－0.2%~－0.6%。 Amazon.com表明，页面加载时间只需减少100ms，就会带来1%的收入增长（注2）。其他研究表明，用户希望网站在两秒钟内加载，如果网站做不到，有近三分之一的用户就会访问别的网站。而且，这些用户几乎是一去不复返。Google已经优化了其搜索算法的速度，所以如果你的网站很慢，你的网站就不可能出现在Google搜索结果的第一页。因此网站的性能（精确到毫秒）是相当重要的。
有很多办法可以提高网站的性能，这些办法可以分为两大类：限制文件大小或者减少服务器的请求数量。下面的列表仅仅是网站优化的简单技术，但它会给你提供一些总体思路。
优化图像，使图像在没有质量损失的条件下最小。你将在第22章中学习这个技术。
最小化HTML和CSS文件，去除多余的字符空格和换行回车符。
JavaScript最小化。
加载脚本，使脚本与其他页面资源并行加载，不要影响网页渲染。
不要加载不必要的东西（如图片、脚本、JavaScript库）。
减少浏览器给服务器发送请求（即HTTP请求）的次数。
服务器每次收到HTTP请求都要耗费几毫秒的时间，而那些毫秒累加起来就不得了。Twitter小工具、Facebook的Like按钮和广告都会产生几十个服务器请求。你可能会惊讶地看到，甚至一个简单的网站都会产生非常多的服务器请求。
如果你想自己看看，你可以使用Chrome浏览器中的开发工具来看每一个发送到服务器的请求，以及这些请求需要的毫秒数。下面告诉你如何使用这个工具：

1. 打开Chrome浏览器，随便打开一个网页。
2. 打开View菜单，选择Developer→Developer Tools。浏览器的下端就会打开一个面板。
3. 选择工具中的Network标签，并重新载入页面。这个图（通常简称为瀑布图）显示了所有的请求和下载的资源。在右边的列显示了每个请求花费的时间（以毫秒为单位）。在底部的图表，你可以看到发出的请求的总数和传输的数据总量。
   图3-5显示了我的网站Jenville.com上的一部分性能瀑布图，我的网站只是一个简单的站点（但也不是那么简单）。你可以用这个方法来查看任何网站。看了之后，你会收获颇丰。

开发人员创建的瀑布图工具显示页面产生的每个请求，以及每个请求所需耗费的时间
在本书中我不会提及太多的站点性能，但是我确实想让你明白尽可能减小文件大小和省去不必要的服务器请求的重要性。
进一步阅读
还有一些其他的技术对这本书来说太有技术含量了（坦白说，是对于我），我认为如果你只看这本书，并不能成为一个站点性能高手。但是如果你能看看下面的书，会对你有很大的帮助：
Google站点上的Make the Web Faster（code.google.com/speed/）是学习站点优化的第一站。它汇编了很多优秀的教程和文章，以及测量站点速度的工具。
Steve Souders 所著（O扲eilly Media出版）的《High Performance Web Sites》和《Even Faster Web Sites》，这两本书提供了很多加快站点速度的实践经验。阅读它们需要对JavaScript和服务器功能有良好的理解。