vs2015页面设置_2015年平均页面重量增加了16％

vs2015页面设置

It’s happened again. The HTTP Archive Report, which collates technical information from half a million of the web’s most popular websites, reports that average page weight increased 16% during 2015 to reach 2,262KB. A similar increase was observed in 2014.

又发生了 HTTP存档报告收集了来自全球50万个最受欢迎网站的技术信息，该报告称，平均页面重量在2015年增长了16％，达到2,262KB。 2014年也有类似的增长 。

The report analyzes publicly-accessible content and shopping web sites. It cannot analyze web applications or pages behind a login such as Facebook.

该报告分析了公众可访问的内容和购物网站。 它无法分析Web应用程序或登录后的页面(例如Facebook)。

technology	end 2014 (KB)	end 2015 (KB)	increase (%)
HTML	59	66	12%
CSS	57	76	33%
JavaScript	295	363	23%
Images	1,243	1,443	16%
Flash	76	53	-30%
Other	223	261	17%
Total	1,953	2,262	16%

技术	2014年底(KB)	2015年底(KB)	增加 (％)
HTML	59	66	12％
CSS	57	76	33％
JavaScript	295	363	23％
图片	1,243	1,443	16％
闪	76	53	-30％
其他	223	261	17％
总	1,953	2,262	16％

Figures are averages. Page weights are unlikely to follow a normal distribution but the numbers seem reasonable when you dissect pages around the web.

数字是平均值。 页面权重不太可能遵循正态分布，但是当您在网络上剖析页面时，数字似乎是合理的。

HTML content has risen by 7KB. Is the average article 12% longer? I doubt it.

HTML内容增加了7KB。 平均文章长12％吗？ 我对此表示怀疑。

Unsurprisingly, Flash has also dropped by 23KB or 30%. One in five sites continue to use Flash — a drop of 26% over the year.

毫不奇怪，Flash也减少了23KB或30％。 五分之一的站点继续使用Flash-一年下降了26％。

CSS increased by 19KB. There’s little excuse for using eight stylesheets but the overall file size hike seems reasonable given:

CSS增加了19KB。 使用八个样式表几乎没有任何借口，但鉴于以下因素，总体文件大小的增加似乎是合理的：

1. CSS capabilities increase over time. We’re using effects, animations and responsive layouts which were not possible a few years ago (whether they’re necessary is another matter).
   CSS功能随时间增加。 我们正在使用几年前无法实现的效果，动画和响应式布局(是否有必要是另一回事)。
2. Pre-processors such as Sass, LESS and Stylus have a tendency to bulk code because nesting and property reuse is easy.
   诸如Sass，LESS和Stylus之类的预处理器具有大量代码的趋势，因为嵌套和属性重用很容易。
3. Build tools make it easier to inline image assets.
   构建工具使内联图像资产更加容易。

Features such as CSS Flexbox can help reduce more complex float-based layouts but the savings are fairly minimal.

CSS Flexbox之类的功能可以帮助减少更复杂的基于float的布局，但是节省的成本却很小。

You could have expected JavaScript code to drop accordingly but it’s grown by 68KB to reach 363KB distributed over 22 separate files. That’s a lot of code. Some will be frameworks and libraries, but I suspect the majority is social media widgets and advertising.

您可能希望JavaScript代码会相应地下降，但是它增加了68KB，达到363KB，分布在22个单独的文件中。 那是很多代码。 其中一些将是框架和库，但我怀疑其中大多数是社交媒体小部件和广告。

Other files, such as fonts and videos, have increased by 38KB or 17%.

其他文件，如字体和视频，增加了38KB或17％。

As usual, the biggest rise is from images. We’re loading an additional 200KB, which accounts for 65% of the overall growth. 55 separate image files are accessed per page, which seems excessive.

像往常一样，最大的增长来自图像。 我们正在加载额外的200KB，占整体增长的65％。 每页访问55个单独的图像文件，这似乎过多。

Other highlights lowlights:

其他 亮点 不足：

• 25% of sites do not use GZIP compression
  25％的网站不使用GZIP压缩
• 101 HTTP file requests are made — up from 95 a year ago
  发出了101个HTTP文件请求-一年前为95个
• pages contain 896 DOM elements — up from 862
  页面包含896个DOM元素—从862起
• resources are loaded from 18 domains
  从18个域中加载资源
• 49% of assets are cacheable
  49％的资产可缓存
• 52% of pages use Google libraries such as Analytics
  52％的页面使用Google库，例如Google Analytics(分析)
• 24% of pages now use HTTPS
  现在有24％的页面使用HTTPS
• 36% of pages have assets with 4xx or 5xx HTTP errors
  36％的页面具有4xx或5xx HTTP错误的资产
• 79% of pages use redirects
  79％的页面使用重定向

为什么页面膨胀？ (Why Have Pages Bloated?)

There’s a simple explanation for 2.2MB pages: we’re doing a terrible job.

对于2.2MB的页面，有一个简单的解释： 我们做得很糟糕 。

As a developer, I love the web. As a user, it’s often awful. Sites are desperate to “increase engagement” with intrusive advertising, annoying pop-ups, under-used social media cruft and invasive tracking. Perhaps this leads to momentary revenue gains, but the increased bloat is counter-productive:

作为开发人员，我喜欢网络。 作为用户，这通常很糟糕。 网站迫切希望通过介入性广告，烦人的弹出式窗口，未充分使用的社交媒体功能和侵入性跟踪来“增加参与度”。 也许这会带来暂时的收益增长，但是膨胀的增加会适得其反：

• Google downgrades heavyweight sites which can harm search engine optimization efforts.
  Google降级了重量级网站，这可能会损害搜索引擎的优化工作。

• Advertising claims to keep content free. Will users consider it free when they discover it costs $0.40 to view one page on a typical mobile data plan?

  广告声称保持内容免费。 当用户发现在典型的移动数据计划中浏览一页的费用为0.40美元时，用户是否会认为它免费？

• The elevation of ad-blockers to mainstream consciousness during the year highlights user frustrations and the ease at which anyone can abolish irritating content.
  在这一年中，广告拦截器逐渐成为主流意识，这凸显了用户的挫败感以及任何人都可以消除令人讨厌的内容的便捷性。

• Users do not wait. Etsy.com discovered that 160KB of additional images caused their bounce rate to increase 12% on mobile devices.

  用户不用等待。 Etsy.com发现，在移动设备上160KB的其他图像导致其跳出率提高了12％。

• Web activities are starting to attract government attention. For example, UK mobile operators can be fined if a service using their network makes gains from misleading campaigns. Regulation will inevitably escalate as sites become more desperate.
  网络活动开始引起政府关注。 例如，如果英国移动运营商使用其网络的服务因误导性活动而获得收益，则可能被罚款。 随着场所变得更加绝望，监管将不可避免地升级。

Content is being drowned in cruft. Uncompressed, Shakespeare’s 37 plays total more than 800 thousand words or a 5MB download. Now consider Facebook’s Instant Articles overview which suggests an alternative to bloated pages. It contains five paragraphs yet, ironically, requires 3.5MB bandwidth plus another 50MB when you view the three-minute video. Does it convey more information than the combined works of Shakespeare? Perhaps it’s prettier, but is it necessary to show a 267KB image of a chap holding an invisible ferret?

内容被淹没。 莎士比亚的37首歌曲未经压缩，总共播放80万多个单词或下载5MB。 现在考虑一下Facebook的Instant Articles概述 ，该概述提出了一种替代pages肿页面的方法。 具有讽刺意味的是，它包含五个段落，当您观看三分钟的视频时，它需要3.5MB带宽以及另外的50MB带宽。 它传达的信息比莎士比亚的著作还多吗？ 也许它更漂亮，但是是否有必要显示一个267KB的图像，其中包含一个看不见的雪貂？

肥胖否认 (Obesity Denial)

I’ve published several of these articles. Many claim there is no obesity crisis, so let’s tackle the primary arguments.

我已经发表了其中几篇文章。 许多人声称没有肥胖危机，因此让我们解决主要争论。

Some pages will always be big Image galleries, games, technical showcases etc. will always be chunky. Yet every developer can justify the weight of their pages. The HTTP Archive Report mostly analyzes content articles and online shops. 2.2MB per page — the equivalent of half Shakespeare’s plays — is ridiculous.

一些页面将永远是大型图像库，游戏，技术展示等，将始终是块状的。 但是每个开发人员都可以证明其页面的合理性。 HTTP存档报告主要分析内容文章和在线商店。 每页2.2MB( 相当于莎士比亚剧本的一半)非常荒谬。

Page weight is not an indication of quality In my experience, page weight is inversely proportional to quality. Bulky pages are often link-bait articles or meaningless marketing extravaganzas. There are exceptions, but wouldn’t it be great if there were a tool to rate content and compare that against bloat?

页面重量不是质量的指标根据我的经验，页面重量与质量成反比。 庞大的页面通常是链接诱饵文章或毫无意义的营销盛宴。 有例外，但是如果有一种工具可以对内容进行评级并将其与膨胀进行比较，那不是很好吗？

Users never complain about overweight pages …because they abandon them. Analytics record those who successfully access a site. They won’t highlight those who couldn’t load obese pages or never returned again.

用户永远不会抱怨超重页面 ……因为他们放弃了它们。 Google Analytics(分析)会记录那些成功访问网站的人。 它们不会突出显示那些无法加载肥胖页面或永远不会再返回的页面。

Bandwidth capacity increases every year — page weight is negated Did your bandwidth on all networks increase by 16% in 2015? And 15% in 2014? And 32% in 2013? And 30% in 2012?

带宽容量逐年增加—忽略页面权重 2015年，您所有网络上的带宽是否增加了16％？ 2014年占15％ ？ 2013年占32％ ？ 2012年占30％ ？

Even if it did, it doesn’t follow everyone had the same experience. Smartphone access is exploding, yet mobile networks remain slow in many places around the world.

即使这样做，也不会跟随每个人都有相同的经验。 智能手机的访问量呈爆炸式增长，但移动网络在世界许多地方仍然很慢。

Even if we presume connectivity is excellent everywhere, do developers have a duty to use the increased capacity? Have pages become 16% better than last year?

即使我们认为到处的连接性都很好，开发人员是否有义务使用增加的容量？ 页面比去年好了16％吗？

Slimming pages means dumbing down, with fewer features and effects Why? In some cases sites can make incredible savings with a few minutes’ effort. Activating compression and concatenating assets won’t change anything except performance.

缩小页面意味着笨拙，功能和效果更少为什么？ 在某些情况下，只需花费几分钟的时间， 网站就可以节省大量资金 。 激活压缩和连接资产不会改变性能。

An obsession with performance leads to more complication and maintenance Removing unused or unnecessary images, assets, features and widgets simplifies a site. It’ll lead to fewer complications and less maintenance. No one is suggesting you should fret over every byte, but look after the kilobytes and the megabytes will look after themselves.

对性能的痴迷导致更多的复杂性和维护工作。删除未使用或不必要的图像，资产，功能和小部件可简化站点。 这将减少并发症并减少维护工作。 没有人建议您为每个字节烦恼，但要照顾千字节，兆字节将照顾自己。

Additional page weight is the price of progress In some edge cases, perhaps. Lightsaber Escape has a 120MB payload because it’s a revolutionary and experimental browser-based game (which is not analyzed by the HTTP Archive). Can the same be said for Apple’s 11.2MB iPhone 6S page, which delivers a few paragraphs and effects which (mostly) could have been achieved a decade ago in a fraction of the size?

页面的额外权重是进度的代价，在某些情况下，也许是这样。 Lightsaber Escape具有120MB的有效负载，因为它是一款革命性的实验性基于浏览器的游戏(HTTP存档未对此进行分析)。 苹果的11.2MB iPhone 6S页面可以说同样的话吗 ，该页面提供了几段和效果(大多数)可以在十年前实现，但尺寸只是它的一小部分？

SitePoint’s pages often exceed 2MB Ahem. Oh look — a squirrel…

SitePoint的页面经常超过2MB 。 哦，瞧， 一只松鼠…

SitePoint pages can be heavy on desktop devices, although they reduce to a few hundred kilobytes when viewed on a small-screen over a slower network. No site is perfect, and performance efforts are being made, but I agree it could be improved.

尽管在较慢的网络上的小屏幕上查看时，SitePoint页面在桌面设备上可能很繁重，但它们可以缩小到数百KB。 没有哪个站点是完美的，并且正在努力提高性能，但是我同意可以对其进行改进。

Why should I bother? Few others do The reason: there’s no downside. Your users benefit from more responsive pages and a slicker experience. Your search engine ranking improves. Your conversions increase. Your hosting charges drop. You’re even reducing electricity consumption and doing your bit to save the planet. It’s a little extra effort, but the most drastic optimizations result from the simplest changes — see The Complete Guide to Reducing Page Weight.

我为什么要打扰？ 很少有人这样做 。原因： 没有缺点 。 您的用户将从响应速度更快的页面和流畅的体验中受益。 您的搜索引擎排名会提高。 您的转化次数增加。 您的托管费用下降。 您甚至在减少电力消耗，尽一切努力拯救地球。 这需要一些额外的工作，但是最简单的更改是最激烈的优化-请参阅《减少页面重量的完整指南》 。

昏迷肥胖 (Unconscious Obesity)

Developers and site owners unconsciously created the obesity epidemic, but considerable savings can be made by addressing:

开发人员和网站所有者在不知不觉中造成了肥胖病的流行，但是通过解决以下问题，可以节省大量资金：

1. Images and videos. Is a hero necessary? Can the file be resized or reduced? Could it be replaced with CSS effects? Are content managers uploading monolithic files? Will any user see all 55 images?
   图片和视频。 英雄有必要吗？ 可以调整文件大小或缩小文件吗？ 可以用CSS效果代替吗？ 内容管理员是否正在上传整体文件？ 会有用户看到全部55张图片吗？

2. Third-party content. Advertising and social media scripts can be ludicrously wasteful. Are they necessary? Are there better options?

   第三方内容。 广告和社交媒体脚本可能浪费很大 。 他们有必要吗？ 有更好的选择吗？

3. Attitude. Performance rarely concerns those sitting on a 100MB connection. Try throttling bandwidth, connecting via 3G or using hotel Wi-Fi for a while — it may change perceptions.
   态度。 性能很少涉及那些使用100MB连接的用户。 尝试节流带宽，通过3G连接或使用酒店的Wi-Fi一段时间-这可能会改变看法。

It’s far easier to gain weight than lose it. Adding a few extra widgets or graphics seems reasonable, but it soon mounts up. Going back and removing superfluous junk can be tedious and difficult. The answer seems obvious: don’t add it in the first place.

减肥远比减肥容易。 添加一些额外的小部件或图形似乎很合理，但是很快就会安装上。 返回并清除多余的垃圾可能是乏味且困难的。 答案似乎很明显： 不要首先添加它 。

Few site owners care about bloat. Performance is a developer mind-set. Consider it from the start of the project and it will not significantly increase development time. Addressing performance after your pages hit obese levels is too late.

很少有网站所有者关心膨胀。 性能是开发人员的心态。 从项目开始就考虑它，它不会显着增加开发时间。 在页面达到肥胖水平后再处理性能为时已晚。

翻译自: https://www.sitepoint.com/average-page-weight-increased-another-16-2015/

vs2015页面设置