Internet发展非常迅速，因此我们创建了Web平台。通常我们会忽略连接性等问题，但用户不会。瞥一眼万维网的当前状态就会发现，我们在构建它时并没有同情心、灵活性，更不用说性能了。那么，当今的网络状况如何？在这个星球上的74亿人中，只有46%可以访问互联网。平均互联网速度上限为7Mb/s。更何况，93%的互联网用户都是通过移动设备访问的——如果不适合移动设备，用户会反感。数据通常比我们想象的要贵-购买500MB数据包可能需要1到13个小时（德国与巴西；请参阅BenSchwarz的BeyondtheBubble：TheRealWorldPerformance了解更多有趣的统计数据）。我们的网站也不是完美的——平均网站大小是原始Doom游戏的大小（大约3MB）（请注意，为了统计准确性，应该使用中位数，阅读IlyaGrigorik的优秀“平均页面”是一个神话，中期-Range网站大小目前为1.4MB）。图片很容易占用1.7MB的带宽，而JavaScript平均占用400KB。这不仅仅是一个网络平台问题，原生应用程序可能更糟，还记得下载200MB安装程序只是为了获得错误修复版本吗？技术人员经常发现自己处于特权地位。使用最新的高端笔记本电脑、手机和快速有线互联网连接，很容易忘记这些并不是适合所有人的条件（实际上，很少，真的）。如果我们从特权和缺乏同理心的角度来框架网络平台，那么就会导致排他性的糟糕体验。考虑到设计和开发性能，我们如何才能做得更好？优化所有资源了解浏览器如何分析和处理资源是显着提高性能的最强大但未充分利用的方法之一。事实证明，浏览器非常擅长在解析资源并确定其优先级时嗅探资源。这是密钥请求的来源。如果请求包含在用户视口中呈现内容所需的资源，则该请求是关键的。对于大多数网站，它将是HTML、必要的CSS、徽标、网络字体，可能还有图像。在许多情况下，许多其他不相关的资源（JavaScript、跟踪代码、广告等）正在影响关键请求。幸运的是，我们可以通过仔细挑选重要资源并确定其优先级来控制这种行为。我们可以手动强制提高资源的优先级，以确保按时呈现所需的内容。这种技术可以显着改善“交互时间”指标，从而实现最佳的用户体验。对许多人来说，关键请求仍然像是一个黑匣子，缺乏可共享的材料并没有改变这一点。幸运的是，BenSchwarz就此问题发表了一篇非常全面且平易近人的文章-CriticalRequest。另请参阅Addy的文章，Chrome中的预加载、预取和优先级。[在Chrome开发者工具中启用优先级]要跟踪请求优先级的情况，请使用Lighthouse性能工具和关键请求链审核工具，或查看Chrome开发者工具类中“网络”选项卡下的“请求优先级”。一般性能检查表缓存积极启用压缩优化关键资源的优先级使用CDN（内容交付网络）优化图像图像通常占网页交付的大部分负载，因此图像优化可以带来最大的性能提升。有很多现有的策略和工具可以帮助我们去除多余的字节，但首先应该考虑的问题是：“图像对我要传达的信息和效果是否至关重要？”。如果你可以消除它，你不仅可以节省带宽，还可以节省请求。在某些情况下，可以使用不同的技术实现类似的结果。例如，CSS具有一系列艺术方向属性，如阴影、渐变、动画和形状，这些属性使我们能够构建适当样式的DOM元素。选择正确的格式如果您不能放弃图像，那么确定哪种格式更合适就很重要。首先要做的是在矢量图和光栅图形之间进行选择：矢量图：与分辨率无关，通常较小。非常适合徽标、图标和简单图形，包括基本形状（直线、多边形、圆形和点）。光栅图形：呈现更详细的信息，更适合照片。做出第一个决定后，您可以从多种格式中进行选择：JPEG、GIF、PNG–8、PNG–24或较新的WEBP和JPEG-XR格式。有这么多选择，我们如何确保做出正确的选择？下面是确定最佳格式的基本方法：JPEG：颜色非常丰富的图像（例如照片）PNG–8：相对单色的图像PNG–24：部分透明的图像GIF：动画Photoshop可以使用各种设置优化上述每种格式，例如降低质量、减少噪声或颜色数量。确保设计人员了解上述性能实践，并能够以正确的方式优化适当格式的图像。如果您想了解有关如何使用图像的更多信息，请阅读LaraHogan的优秀文章DesigningforPerformance。尝试新格式图像格式中有几个较新的播放器，即WebP、JPEG2000和JPEG-XR。它们都是由浏览器供应商开发的：Google的WebP、Apple的JPEG2000和Microsoft的JPEG-XR。WebP是最受欢迎的竞争者，同时支持无损和有损压缩，这使得它非常灵活。无损WebP比PNG小26%，比JPG小25-34%。凭借74%的浏览器支持，WebP可以安全降级，最多可节省1/3的传输字节。JPG和PNG可以在Photoshop和其他图像处理应用程序以及命令行界面（brewinstallwebp）中转换为WebP。如果你想探索其他格式之间的视觉差异，我推荐Github上的这个很棒的演示。使用工具和算法进行优化即使使用高效的图像格式，也不应跳过后处理优化。这一步非常重要。如果您选择相对较小的SVG，它们也是可重新压缩的。SVGO是一种命令行工具，可通过去除不必要的元数据来快速优化SVG。此外，如果您更喜欢Web界面或受操作系统限制，请使用JakeArchibald的SVGOMG。因为SVG是一种基于XML的格式，所以它也可以在服务器端进行GZIP压缩。ImageOptim是大多数其他图像类型的最佳选择。包括pngcrush、pngquant、MozJPEG、GoogleZopfli等，它在一个全面的开源包中捆绑了一堆很棒的工具。ImageOptim可以作为MacOS应用程序、命令行界面和Sketch插件轻松实施到现有工作流程中。对于Linux或Windows上的用户，大多数ImageOptim的CLI都可以在您的平台上使用。如果您倾向于尝试新兴的编码器，Google今年早些时候发布了Guetzli——一种源自WebP和Zopfli的开源算法。Guetzli可以生成比任何其他可用压缩方法小35%的JPEG。唯一的缺点：处理时间慢（CPU处理每百万像素需要1分钟）。选择工具时，请确保它们生成所需的结果并适合您团队的工作流程。理想情况下，优化过程应该是自动化的，这样就不会遗漏任何东西。响应式图片十年前，我们使用一种分辨率为所有人服务，但是时代变化太快了，以至于今天的响应式网络已经不是以前的样子了。这就是为什么我们必须特别注意仔细优化视觉资产并确保它们适用于各种视口设备。幸运的是，感谢ResponsiveImages社区组，我们可以完美地使用picture元素和srcset属性（均有85%+的支持）。srcset属性srcset在分辨率切换场景下效果最好——即当我们需要根据用户的屏幕密度和尺寸显示图像时。基于srcset和size属性中的一组预定义规则，浏览器将相应地选择最佳图像以提供给视口。这种技术可以带来巨大的带宽和请求节省，尤其是对于移动用户。[srcset使用示例]picture元素picture元素和media属性旨在使艺术设计变得容易。通过为不同的情况提供不同的图像（通过媒体查询测试），无论分辨率如何，我们始终可以使图像中最重要的元素保持在焦点上。[图片元素使用示例]请务必阅读JasonGrigsby的ResponsiveImages101指南，以全面了解这两种方法。使用图像CDN进行视觉优化的最后一步是分发。所有资产都可以从使用CDN中获益，但也有针对图像优化的特定工具，例如Cloudinary和imgx。使用这些服务的好处远远不止减少服务器上的流量和显着减少响应延迟。CDN可以很好地解决图片密集型网站的复杂性，包括响应式服务和图片优化。虽然产品各不相同（价格也不同），但大多数方案都是基于设备和浏览器、调整大小和裁剪来确定哪种格式最适合用户。甚至更多——它们可以压缩、检测像素密度、水印、识别人脸，并支持后期处理功能。有了这些强大的功能，以及将参数附加到URL的能力，提供以用户为中心的图像变得很容易。图像性能检查表选择正确的图像格式尽可能使用矢量图形使用新格式图像使用工具和算法进行优化学习srcset和图片使用图像CDNWeb字体优化自定义字体是一个非常强大的设计工具。但是随着权力而来的是很多责任。现在有68%的网站使用网络字体，这种类型的资源是性能杀手之一（平均容易达到100KB，具体取决于变体和字体的数量）。即使大小不是最大的问题，隐形文本闪现(FOIT)才是。FOIT发生在网络字体加载或加载失败时，留下空白页面并使内容无法访问。可能值得仔细检查我们是否首先需要网络字体。如果是这种情况，有一些策略可以帮助我们减轻对我们业务的负面影响。选择正确的格式有4种网络字体格式：EOT、TTF、WOFF和最近的WOFF2。TTF和WOFF应用广泛，90%以上的浏览器支持。根据支持情况，使用WOFF2并在旧版浏览器中回退到WOFF最有可能是安全的。使用WOFF2的优势是一组自定义的预处理和压缩算法（例如Brotli），文件大小减少了大约30%，解析能力也得到了提高。在@font-face中定义网络字体的来源时，使用format()提示指定应使用哪种格式。如果您使用GoogleFonts或Typekit提供字体，两者都会实施优化其性能的策略。Typekit现在异步地为所有工具包提供服务，防止FOIT并为其JavaScript工具包代码允许10天的延长缓存期（而不是默认的10分钟）。GoogleFonts会根据用户的设备自动提供最小的文件大小。查看字体范围无论是否自托管，字体数量、字体大小和样式都会显着影响您的性能预算。理想情况下，我们只需要一种既包含常规字体又包含粗体的字体。如果您不确定如何选择字体范围，请参阅LaraHogan的称重美学和性能。使用Unicode范围子集Unicode范围子集允许将大字体拆分为较小的集。这是一个相对高级的策略，尤其是在处理亚洲语言时，可以带来显着的节省（您知道中文字体平均有20,000个字形吗？）。第一步是将字体限制为必要的语言集，例如拉丁文、希腊文或西里尔文。如果您仅将Web字体用于徽标类型，则应使用Unicode范围描述符来选择特定字符。FilamentGroup发布了一个开源命令行工具，该工具可以从文件或URL中生成带有必要字形列表的字形挂钩。或者，基于Web的FontSquirrelWebFontGenerator提供高级子集和优化选项。如果使用GoogleFonts或Typekit的语言子集被内置到字体选择器界面中，则可以使基本子集更容易。建立字体加载策略字体是渲染阻塞的——因为浏览器必须首先构建DOM和CSSOM；浏览器在使用与现有节点匹配的CSS选择器之前不会下载Web字体。此行为会显着延迟文本呈现，通常会导致前面提到的不可见文本闪烁(FOIT)。FOIT在较慢的网络和移动设备上会更加明显。实施字体加载策略以防止用户无法访问您的内容。通常，选择FlashUnstyledText(FOUT)是最简单和最有效的解决方案。font-display是一个新的CSS属性，它提供了一个不依赖JavaScript的解决方案。不幸的是，它只有部分支持（Chrome和Opera），目前正在Firefox和WebKit中开发。尽管如此，它可以而且应该与其他字体加载机制结合使用。[font-displayattributeinpractice]幸运的是，Typekit的WebFontLoader和BramStein的FontFaceObserver可以帮助管理字体加载行为。此外，网络字体性能专家ZachLeatherman发布了字体加载策略综合指南，可帮助您为项目选择正确的方法。字体性能检查表选择正确的格式使用Unicode范围子集审核字体范围建立字体加载策略JavaScript优化JavaScript目前的平均大小为446KB，使其成为第二大资源类型（仅次于图像）。我们可能没有意识到，我们喜爱的JavaScript隐藏着更严重的性能瓶颈。监控JavaScript的流量优化交付只是解决网页膨胀的第一步。下载JavaScript后，浏览器必须对其进行解析、编译和运行。快速浏览一些流行的网站，很明显gzip后的JS在解压时至少大三倍。事实上，我们正在发送一大堆代码。1MBJavaScript在不同设备上的解析时间。图片由AddyOsmani和他的JavaScript启动性能文章提供。分析解析和编译时间对于了解应用程序是否已准备好进行交互至关重要。这些时间因用户设备的硬件功能而异。在低端手机上解析和编译可以轻松提高2-5倍。Addy的研究证实，在普通手机上，应用程序需要16秒才能达到交互状态，而在台式电脑上则需要8秒。分析这些指标至关重要，幸运的是，我们可以使用ChromeDevTools来完成。[请参阅ChromeDevTools中的解析和编译]请务必阅读AddyOsmani对JavaScript启动性能的详细解释。摆脱不必要的依赖现代包管理器的工作方式是轻而易举地掩盖依赖的数量和大小。webpack-bundle-analyzer和BundleBuddy是出色的可视化工具，可帮助识别代码重复、最大的性能问题以及过时的、不必要的依赖项。图webpackbundleanalyzerinpractice通过VSCode和Atom中的ImportCost扩展，我们可以让importdependencycosts更加明显。实施代码拆分只要有可能，我们就应该只提供用户体验所必需的资源。向用户发送一个完整的bundle.js文件，包括处理他们可能永远看不到的交互的代码，不太理想（假设在访问登录页面时，下载了处理整个应用程序的JavaScript）。同样，我们通常不应提供特定于浏览器或用户代理的标签。Webpack是最流行的模块打包器之一，具有原生代码拆分支持。最简单的代码拆分可以按页面实现（比如登陆页面用home.js，联系页面用contact.js等），Webpack也提供了一些高级的策略，比如动态导入和懒加载，值得一看.考虑框架选择JavaScript前端框架瞬息万变。根据2016年JavaScript调查，React是最受欢迎的选择。仔细查看架构选择可能会发现您可以使用更轻量级的替代方案，例如Preact（请注意，Preact不是React的完全重新实现，只是一个高性能、轻特性的虚拟DOM库）。同样，我们可以用较小的版本替换较大的库-用于date-fns的moment.js（或者在特定情况下，删除moment.js中未使用的语言环境）。在开始一个新项目之前，有必要确定需要什么功能，并根据您的需求和目标选择性能最高的框架。有时这可能意味着选择编写更多普通的JavaScript。JavaScript性能清单监控JavaScript流量摆脱不必要的依赖实施代码拆分考虑框架选择性能跟踪，前进的方向我们已经讨论了一些策略，在大多数情况下，这些策略将对我们正在开发的产品的用户体验产生积极影响建筑。性能可能是一个棘手的问题，并且有必要随着时间的推移跟踪我们调整的结果。以用户为中心的性能指标卓越的性能指标旨在尽可能接近地描述用户体验。传统上，onLoad、onContentLoaded或SpeedIndex提供的关于用户与页面交互的速度的信息很少。当关注交通资源时，很难定量地感知性能。幸运的是，有一些时间可以充分描述内容的可见性和交互性。这些指标是“首次绘制”、“首次有意义的绘制”、“视觉完成度”和“交互时间”。FirstRender：浏览器从白屏到第一次视觉渲染的过渡。第一次有意义的渲染：文本、图像和主要内容都可见。视觉上完整：视口中的所有内容都可见。可交互时间：视口中的所有内容都是可见的并且可以与之交互（JavaScript主线程停止活动）。这些时间直接对应于用户的实际体验，因此可以作为焦点进行跟踪。如果可能，将它们全部记录下来，否则选择一两个以更好地监控性能。还有其他指标也需要关注，特别是我们发送的字节数（优化和解压缩）。设定绩效预算所有这些报告的数字很快就会变得令人困惑和难以理解。没有可操作的目标和目标，很容易忘记我们最初的目的。几年前，蒂姆·卡德莱克(TimKadlec)撰写了有关绩效预算概念的文章。不幸的是，没有适用于所有情况的神奇公式。绩效预算通常归结为竞争分析和产品目标，这对每个企业都是独一无二的。设定预算时，实现显着差异很重要，通常至少有20%的改善。使用LaraHogan的方法新设计和性能预算作为参考，练习和迭代您的预算。尝试性能预算计算器或Chrome扩展浏览器卡路里来帮助创建预算。连续监控监控性能不应是手动的。有许多强大的工具也可以提供全面的报告。GoogleLighthouse是一个开源项目，可以审核性能、可访问性、渐进式网络应用程序等。您可以在命令行或直接在Chrome开发者工具中使用Lighthouse。[Lighthouse运行性能审查]对于持续跟踪，选择Calibre，它提供性能预算、设备模拟、分布式监控和许多其他功能，而无需我们仔细构建自己的性能套件。[口径报告]无论您在跟踪什么，请确保您的整个团队或组织都可以透明地访问数据。性能是一项共同责任，远远超过开发人员团队-我们都对我们创造的用户体验负责，无论角色或级别如何。提倡速度并建立协作流程非常重要，这样可能遇到的瓶颈就会在产品决策或设计阶段的早期暴露出来。建立绩效意识和同情心关注绩效不仅仅是一个业务目标（但如果您需要销售统计数据来进行销售，那就是通过PWA统计数据）。首先是基本的同理心和用户体验。作为技术人员，我们的责任不是让用户的注意力和时间花在等待页面上，而是可以更愉快地花在其他地方。我们的目标是构建能够感知时间和人们注意力的工具。提升绩效意识应该是每个人的目标。让我们用表现和同情心为每个人建设一个更美好、更有意义的未来。
