2013年 , 页面总重量增加了32%,达到可笑的1.7Mb和96个单独的HTTP请求。 这是一个平均数字; 所有网站的一半将更大。 网站肥胖症已成为一种流行病,我们的网站开发人员应对此负责。 没有任何借口。
超重的网站会对您的利润产生不利影响:
我预计今年的页面重量将下降 ,我希望不要被证明是错误的。 幸运的是,有许多快速修复程序将对站点性能产生即时影响。 所有这些技术都是众所周知的,使用当今的技术,不需要花费大量时间,并且可以在现有代码库上实现,而无需重新开发。 稍后,我将继续介绍更高级的技术,然后概述一些工具来帮助您评估成功。
前三个实际上并没有使您的网站变瘦,而是将其放在紧身胸衣和讨人喜欢的衣服中……
根据W3Techs.com ,几乎所有网站中的一半都未启用压缩功能。 这通常是服务器设置, 应该由您的Web主机启用,尽管您可以自行配置。
如果浏览器可以轻松地缓存文件,则不一定需要再次下载它。 简单的解决方案包括设置适当的Expires标头 、 Last-Modified日期或在HTTP标头中采用ETag 。
您可能可以将服务器配置为自动处理,例如,这是一个Apache .htaccess设置,用于将所有图像缓存一个月:
ExpiresActive On
ExpiresDefault "access plus 1 month"
浏览器为每个域设置了四个到八个同时HTTP请求的限制。 如果您的页面从您的域中加载了96个资产,那么最多将需要十二套并发请求才能全部出现。 (实际上,文件大小会有所不同,因此不会完全一样,但是限制仍然适用。)
从另一个域请求静态文件实际上使浏览器可以发出的HTTP请求数量增加了一倍。 另外,由于该文件已在其他位置的其他站点上使用,因此用户更有可能预先缓存该文件。 简单的选项是JavaScript库,例如jQuery和字体存储库,但您也可以考虑使用专用的图像托管。
前三个选项有助于提高页面速度,但是我们需要先检查您的代码,然后才能积极减少页面权重…
网站不断发展。 如果您不再使用小部件,则可以删除关联的CSS和JavaScript。 如果它们包含在单独的文件中,那么这很简单。 如果不是这样,您可能需要使用诸如Chrome的Audit Developer Tool、 JSLint、 Dust-Me Selectors 、 CSS Usage 、 未 使用的 css.com之类的工具,或使用诸如grunt-uncss之类的构建工具。
理想情况下,您需要一个CSS文件(尽管如果使用RWD支持IE的旧版本,则可能需要两个CSS文件)。 尽管构建和维护单独的CSS文件可能是明智的,但在将其托管在生产服务器上之前,应将它们加入并删除不必要的空格。
Sass 、 LESS和Stylus等预处理器可以为您完成艰苦的工作。 包括Grunt.js或Gulp在内的构建工具可以使您的工作流程自动化,或者,如果您希望使用GUI,则Koala提供了免费的跨平台应用程序 。
如果这听起来太费力,则可以在文本编辑器中或从命令行(例如,在Windows中)手动串联文件:
copy file1.css+file2.css file.css
或Mac / Linux:
cat file1.css file2.css > file.css
生成的文件可以通过在线CSS缩小器(例如cssminifier.com 、 CSS Compressor&Minifier或CSS Compressor)运行 。
最后,请记住将所有CSS加载到head
以便浏览器知道如何设置后续HTML的样式,而无需再次重新绘制页面。
平均页面加载18个单独的脚本文件。 尽管将jQuery之类的库作为单独的文件保留是可行的,但应在生产服务器上串联并缩小您自己的JavaScript代码。 同样,构建工具可以提供帮助,或者您可以使用在线工具,例如YUI Compressor 、 Closure Compiler或我个人最喜欢的JavaScript CompressorRater ,它将代码传递给多个引擎,以便您选择最佳工具。
诚然,您需要稍微小心一点,因为如果您的代码不好(即使缺少分号),JavaScript压缩器也会失败。 但是,仅串联文件即可提高性能,因为发出的HTTP请求更少。
最后,最好在结束HTML body
标记之前加载JavaScript。 这样可以确保脚本不会阻止其他内容的加载,并且在下载和执行脚本之前可读页面内容。
使用错误的图像格式可能会放大您的页面。 一般来说:
当您使用颜色设置有限的小型图形时,GIF可能会压缩得更好-尽管这种情况很少见。 一些图像也更适合作为矢量,但是我们将在以后的文章中进行讨论。
您将需要一个不错的图形包来转换图像,但是有很多可用的免费选项,例如XnView等使您可以批处理文件。 请记住使用以下设置:
带有3百万像素摄像头的入门级智能手机将产生太大的图像,无法在网页上显示。 不幸的是,内容编辑者将直接从其相机上传图像。 建议稍加教育和自动调整大小的系统。
图片尺寸不得超过其容器的最大尺寸。 如果模板的最大空间为800个水平像素,则图像将不需要更大的宽度。 也就是说,那些使用高密度/视网膜显示器的用户可能会欣赏到1,600像素宽度的两倍图像,但仍然比典型的相机输出要小。
调整图像大小会严重影响页面重量。 将图像尺寸缩小50%将使总面积减少75%,并应大大减小文件大小。
即使您已切换为正确的格式并调整了尺寸大小,也可以使用分析和优化图形的工具来进一步缩小图像文件。 这些包括OptiPNG 、 PNGOUT、 jpegtran和jpegoptim 。 大多数可以作为独立的可执行文件安装,也可以集成到您的构建过程中。 另外,诸如Smush.it之类的在线工具也可以在云中完成工作。
Web字体彻底改变了设计,并减少了对基于图形的文本的需求。 但是,自定义字体会带来一定的成本,并且可能会增加数百千字节的页面大小。 如果您使用的字体超过两种或三种,则可能是过度使用。 您的客户/老板可能喜欢可怕的手写字体,但是,如果仅将其用于一个标题,是否值得下载200KB的字体文件?
我怀疑许多站点可以通过非开发人员的几个小时的努力将其重量减少30-50%。 对于普通站点,这可以节省超过800Kb,而且速度会明显加快。
但是,如果按照这些步骤操作后您的页面仍然肥胖 ,那么您可以考虑使用更多节食方法。
您的页面上是否有Facebook、Twitter、Google +和LinkedIn共享按钮? 您要为沮丧的最终用户提供580Kb的内容 。 大多数JavaScript必须由浏览器执行,并且某些网络规定必须在内容显示之前加载它。
完全不需要膨胀的社交小部件,您可以使用几行HTML 将无脂肪的社交按钮添加到页面中。 少量的JavaScript可以逐步增强体验,并在桌面设备上显示一个弹出窗口。
尽管简单的按钮不会显示点击统计信息,但您可以通过Google Analytics(分析)中的事件跟踪功能找到更多信息。
社交网络并不是唯一的罪魁祸首。 将第三方窗口小部件添加到页面的隐藏成本大大超过了所包含的标记。 即使内容是从另一个域加载的,它也可能包含数百千字节的数据、JavaScript、CSS和图像。
如果必须使用小部件,请考虑编写更好的小部件。 理想情况下,小部件JavaScript应该是轻量级的,应在页面末尾加载,但能够将内容放置在指定的HTML容器中。 或者...
假设您正在显示由专业提供商托管的视频。 虽然仅当用户单击“播放”时才下载视频,但是无论用户是否播放视频,您都可能正在加载视频API代码和其他相关资源。 为什么在用户请求时不加载所有内容?
您还可以考虑在用户滚动页面时下载的点播图像和内容。 我不喜欢这项技术。 它可能会对可用性或SEO产生负面影响。 但是,它对于某些类型的Web应用程序(例如图像库)很有用。
您是否在对图像进行切片以创建渐变、圆形边框和阴影? 我希望不会,因为CSS3使此类技术变得多余。
效果在IE8及以下版本中将不起作用,但是旧的IE即将消失,用户也不会意识到,因为他们不会在多个浏览器中比较您的网站。 您可以添加聪明的垫片,例如CSS3 PIE,但我不建议这样做:它们会使您的页面变大,并使较旧的浏览器缓慢爬行。
CSS3效果通常会正常降低,因此很少需要担心较旧的浏览器。 像素完美始终是徒劳的,在构建适应不同屏幕尺寸的自适应设计时,这简直是荒谬的。
不过要注意一点:在浏览器重绘期间,CSS阴影和渐变已显示出很高的成本,尤其是当您显示添加了这些功能的数十个元素时。 因此,在致力于过度使用这些效果来替换图像之前,请谨慎使用这些效果并测试滚动性能和重新绘制 。
您的JavaScript是否充满$("#x").fade()
和$("#y").slideDown()
效果? 几年前这可能是必需的,但是CSS3 动画 、 过渡和转换在很大程度上已取代了JavaScript效果。 原因:
在某些情况下,您需要细粒度的JavaScript控制,但它们是罕见的例外。 同样,效果在旧的浏览器中将不起作用,但应适当降低。
SVG包含在XML中定义为矢量的点,线和形状。 SVG非常适合于响应式设计,因为它们可以缩放到任意大小而不会降低质量,并且文件大小通常小于位图。
SVG并非在所有情况下都适用。 照片和复杂图像将始终以JPG或PNG格式更好。 但是徽标、图表和图表通常是合适的。 此外,可以使用CSS和JavaScript在客户端上操纵SVG。
有一些工具可以将位图转换为矢量格式,但是从头开始会产生最佳效果。 Illustrator、 Inkscape和SVG edit之类的程序包提供了一个良好的开端,尽管学习XML基础知识将帮助您生成更简洁的代码。
您可能在整个站点中使用了数十个小图标,并且管理单个图像文件并不好玩。 幸运的是, 图标字体可以节省空间和理智。 单个字体可以包含数百个基于矢量的图像,可以在所有浏览器中将其设置为任何颜色并缩放为任意大小(返回IE6)。
您可以使用专用字体,或者为了节省带宽,可以使用Fontello 、 IcoMoon或Flaticon之类的工具来创建包含所需图标的字体包。
一旦CSS3、SVG和图标字体选项被拒绝,位图图像应该是最后的选择。 经常使用的位图可以打包到一个sprite文件中,因此可以在CSS中访问单个图像,例如
.sprite {
width: 16px;
height: 16px;
background: url("sprite.png") 0 0 no-repeat;
}
.sprite.help { background-position: 0 -16px; }
.sprite.info { background-position: 0 -32px; }
.sprite.user { background-position: 0 -48px; }
优点:
可以在图形包中或使用诸如Sprite-Cow和Instant Sprite之类的工具来创建图像精灵。 您也可以将Sprite生产合并到Grunt工作流程中 。
数据URI对二进制和文本资产进行编码,就好像它们是外部资源一样。 位图图像和SVG可以直接用HTML、JavaScript或(更有用的是)CSS编码:
.bullet {
background-image: url("data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAQMAAAAlPW0iAAAABlBMVEUAAAD///+l2Z/dAAAAM0lEQVR4nGP4/5/h/1+G/58ZDrAz3D/McH8yw83NDDeNGe4Ug9C9zwz3gVLMDA/A6P9/AFGGFyjOXZtQAAAAAElFTkSuQmCC");
}
这将减少HTTP请求的数量-尽管除非您以某种方式可以使过程自动化,否则维护会更加困难。 我仅建议将其用于不太可能更改的小型经常使用的图像。
诸如DataURL.net和data:URI Generator之类的工具将为您将文件转换为数据URI。
除非您正在监视页面重量以及由此带来的下载速度提高,否则您不会知道饮食是否成功。 浏览器开发人员控制台和免费的在线工具(例如Google Page Speed Insights)可以提供帮助。 在本系列的最后一部分中,我们将讨论更彻底的,类似吸脂术的页面减重技术之前,将在我的下一篇文章中列出一个完整的列表。
网页减肥很困难。您可以实现快速修复。也许您已经采取了更严厉的措施,比如优化您的CSS和JavaScript。但是,当您的老板/客户要求您提供另一个闪亮的新工具、琐碎的社交网络按钮或古怪的字体时,您所有的好工作都会被抛到一边。
不幸的是,节食的好处往往是有限的。 另一方面,生活方式的急剧改变可以确保您的网站永远不会肥胖。 下面的一些建议有争议,并不适合所有人,但至少,我希望这些建议能使您更多地了解页面重量问题……
您是否会授予未知开发者不受限制的网站代码访问权限? 如果不是,您为什么信任第三方代码? 在页面上添加有用的小部件很容易,而且很少会破坏安全性。 也就是说,请始终检查他们正在使用哪些资源。例如,社交网络按钮可以添加一半兆的内容 ,从而使页面变慢; 没有他们,你能做什么?
也许您正在使用jQuery。 很好– 坚持下去 。 但是,请勿浏览Prototype或YUI插件库来查找酷炫的小部件和效果。
您还应该考虑更多的极端选择:
很少有内容管理系统会生成超重页面…… 但是随后您开始添加内容 。
免费或商业模板可能具有财务意义。 当现成的代码需要花费几美元时,为什么要雇用开发人员呢? 它们对于简单的宣传册站点可能是理想的选择,但存在隐性成本。 通用模板必须出售数百甚至数千个副本,以弥补开发工作。 为了吸引买家,开发人员捆绑了他们可以使用的所有功能。 您只能使用其中的一小部分,但它们仍存在于页面代码中。
也许我不太走运,但是我经历过的WordPress主题通常会超过2Mb。 我敢肯定有轻量级的选择,但是找到一个是另一回事。
样板框架(例如Bootstrap和Foundation)可用于原型设计或作为新项目的起点。 不幸的是,像通用模板一样,它们带有CSS、JavaScript和其他您不需要的资源。 HTML也往往很冗长,并散布着非语义的类名。
就我个人而言,我更喜欢在Web开发中使用类似于lego的模块化方法(这是经典的lego块,而不是限制您构建特定事物的包) 。 您一无所有,然后添加必需的组件。 框架更像是在大理石上雕刻; 您可以清理掉不需要的部分,直到站点完成为止。 那就是应该发生的事情-但是将东西留在里面更容易。
我不会说“不要使用框架” ,但要注意它们带来的额外数量。 诸如grunt-uncss之类的工具可以帮助删除不必要的代码,但最好不要首先添加框架代码。
渐进增强一词已不受欢迎,但这实际上是您在移动优先响应型网站中所做的事情。 本质上,您将通过浏览器支持或要求的功能来创建基本的可用体验,并进行增强。 一个简单的例子:当触发桌面屏幕媒体查询时,您可以在CSS中引用大图像-大多数现代的移动浏览器都不会请求该文件。 您可以使用条件JavaScript加载程序和Network API进一步增强此功能 。
渐进增强很少需要付出额外的努力; 这是一种开发方法,而不是技术。
您应确保在部署之前已完成减少图像、CSS和JavaScript文件的所有操作。 这可能是一个手动过程,但是诸如Grunt.js和Gulp.js之类的自动化工具可以使其轻松 自如 。
CSS和JavaScript预处理程序(例如Sass、LESS、Stylus、CoffeeScript、TypeScript和Dart)可能已经彻底改变了您的生产力和工作流程。 但是,源是从最终生成的代码中抽象出来的。 预处理器输出仅与输入一样好,并且可以以编程方式无意中添加数千条多余的行。 因此,请务必检查以确保输出有效。
Web应用程序可以使用HTML AppCache脱机工作。 可以使用AppCache来补充或增强浏览器对常规使用资产的缓存。
在过去的几年里,web站点和应用程序避开了复杂性,提供了一种精简的、以客户为中心的体验。但并不是每个人都明白这一点,而且不可否认,简化可能比听起来更困难。许多客户都想成为软件设计师,并添加琐碎的功能,因为他们:
幸运的是,稍作用户测试就可以帮助您确定从未使用过的选件,这些选件可以从产品中剔除,也可以用更轻巧的轻巧替代品代替。
谁应该为平均网页达到1.7Mb负责? 开发人员。 网站如何肥胖或肥胖为何都无关紧要。 开发人员让它实现。
当然,开发速度和削减成本很重要。但是如果结果是一个缓慢、笨拙的产品从未使用过,则不重要。 您的客户/老板可能不了解技术问题,但是,如果您不以通俗易懂的方式强调潜在的陷阱,则您永远不会成为尽职尽责的编码人员,赢得应有的尊重和回报。
轻量级页面是高效编码实践的直接结果,并且应该成为任何项目的重要考虑因素。 不幸的是,完成此操作通常会与内容、SEO和可用性测试一起推入“稍后执行”操作。 我的建议:
除非您持续监控页面重量,否则您将不知道饮食的进展情况。 现在 ,平均网页已超过1.7Mb,仅在2013年就增加了32% 。 如果您的开发人员正在暗中研究增肥的窗口小部件,则以下任何评估工具都将突出显示他们的贪婪。 它们都是免费的,只需几秒钟即可运行-您权衡的是…
Pingdom是我最喜欢的在线工具之一。 它揭示了您可能需要了解的所有信息:页面权重、下载速度、代码分析、性能等级、开发建议,甚至是记录饮食进度的历史时间表。 如果仅使用一种分析工具,则应使用Pingdom。
克里斯·佩德瑞克(Chris Pederick)的Web开发者工具栏自创建之初就诞生了(Firefox)。 若要使用它查看压缩和未压缩的页面大小,请从“ 信息”菜单中选择“ 查看文档大小 ”。
请注意,Web Developer可作为Chrome扩展程序使用,但不幸的是,没有此功能。
GTmetrix显示从Google的PageSpeed Insights和YSlow生成的汇总报告,以及其他信息,例如页面总大小和请求数。 尽管您仍然可以单独使用它们,但在线工具比两个系统都好。
PageSpeed Insights不会显示总页面重量或下载速度统计信息,但会指出您可以在哪里改进台式机和移动设备。 网站的得分为100分,因此您可以快速评估改进的进度。
雅虎的YSlow是可用于大多数浏览器的在线工具和插件。 像PageSpeed Insights一样,它会评估页面并针对各种因素在A(您已尽力做到)和F(您失败中失败)之间打分。
如果您不想使用任何新功能,则Firebug、Chrome Inspector、Firefox Web Developer和IE Developer工具都可以提供网络分析器和分析器,以帮助您评估页面的大小。 请注意,它们不一定下载高速缓存的资产,因此您可能需要在测试之前使用Ctrl + F5或清除高速缓存。
如果您需要快速简便的工具,则可以通过“网站速度测试”来完成这项工作。 它着重于下载时间,但也会显示文件大小以及每个单独文件的下载时间,这对于隔离问题区域可能非常方便。
除了通常的大小和下载速度测试外,Uptrends工具也很独特,它使您可以测试特定地理位置的响应能力。 该报告还重点介绍了每种资源的服务领域,以帮助评估CDN的有效性。
Page Speed Tool呈现得很好,并突出显示了文件大小、资产、资源组和下载速度。 请注意,估计的加载时间似乎仅针对HTML源计算,而不是针对所有文件计算。 但是,通过检查随附的瀑布图,可以很好地估算总加载时间。
如果您可以原谅它的年龄以及过时的紫色和橙色设计,则Web Page Analyzer可以提供一系列文件大小统计信息以及调制解调器的下载时间估算,这些数据可以一直返回到14.4K!
我希望这个详尽的指南对您有用,并且至少提供了一些解决方案来帮助您的网页减掉脂肪。祝您新的减肥方法好运!
原文链接: https://www.sitepoint.com/complete-guide-reducing-page-weight/