2014毕业生平均工资
The HTTP Archive Report collates information from almost half a million of the web’s most popular websites. The latest figures indicate that average page weight has increased by 15% in one year to reach 1,953Kb — a little under 2Mb — and comprises 95 individual HTTP requests. While this is smaller than the 32% increase in 2013, it remains cause for concern.
HTTP存档报告会整理来自将近一百万个Web最受欢迎网站的信息。 最新数据表明，平均页面重量在一年内增加了15％，达到1,953Kb(略低于2Mb)，并且包含95个单独的HTTP请求。 虽然这个数字低于2013年的32％ ，但仍令人担忧。
The report analyzes publicly-accessible content and shopping web sites rather than complex web applications and provides a breakdown of the technologies used:
该报告分析了可公开访问的内容和购物网站，而不是复杂的Web应用程序，并提供了所用技术的细分：
technologyend 2013end 2014increaseHTML57Kb59Kb+4%CSS46Kb57Kb+24%JavaScript276Kb295Kb+7%Images1,030Kb1,243Kb+21%Flash87Kb76Kb-13%Other205Kb223Kb+9%Total1,701Kb1,953Kb+15% 技术 2013年底 2014年底 增加 HTML 57Kb 59Kb + 4％ CSS 46Kb 57Kb + 24％ JavaScript 276Kb 295Kb + 7％ 图片 1,030Kb 1,243Kb + 21％ 闪 87Kb 76Kb -13％ 其他 205Kb 223Kb + 9％ 总 1,701Kb 1,953Kb + 15％These are average figures; a large proportion of pages will have greater file sizes.
这些是平均数； 页面的很大一部分将具有更大的文件大小。
A 2Kb rise for HTML seems reasonable although it’s a significant quantity of content given the trend for simpler, more concise text.
HTML的2Kb增长似乎是合理的，尽管考虑到更简单，更简洁的文本的趋势，这是一个很大的内容。
What surprises me most is CSS’s 11Kb rise. Responsive Web Design and CSS3 animations could account for some of this increase but there’s not been a drop in JavaScript. Despite the availability of CSS management and minification tools, the average site also makes six requests for CSS files.
最让我惊讶的是CSS的11Kb增长。 响应式Web设计和CSS3动画可以解决部分这种增长，但是JavaScript并没有减少。 尽管可以使用CSS管理和缩小工具，但平均每个站点还提出了六个CSS文件请求。
JavaScript has risen by 19Kb. This is confusing; the need for shims is reducing, effects can be handed to CSS3 and monolithic libraries have fallen from favor. Sites make an average of 18 JavaScript file requests, which is unchanged from last year — although a quarter of sites make more than 30 requests. Perhaps some of the gain can be explained by increasingly sophisticated/bloated social networking scripts?
JavaScript增加了19Kb。 这很令人困惑。 减少垫片的需求，可以将效果移交给CSS3，单片库已不再受欢迎。 网站平均发出18个JavaScript文件请求，与去年相比没有变化-尽管四分之一的网站发出30个以上的请求。 也许某些收益可以通过日益复杂/过大的社交网络脚本来解释？
27% of sites continue to use Flash — a fall of 5% over the year. The majority is used for advertising, video, and games. Flash hasn’t dropped as fast as expected but its future is clear.
27％的网站继续使用Flash-一年下降了5％。 大部分用于广告，视频和游戏。 Flash的降幅没有达到预期的速度，但是它的未来是明确的。
There’s been a 9% increase for “other” files. That figure doubled in 2013 but, back then, custom fonts and icon fonts were relatively new.
“其他”文件增加了9％。 该数字在2013年翻了一番，但那时，自定义字体和图标字体相对较新。
Finally, images are responsible for 85% of the weight gain. Using high-resolution (Retina) images could account for some of this hike, except:
最后，图像占体重增加的85％。 使用高分辨率(Retina)图像可以解决部分问题，但以下情况除外：
Pages contain more than fifty images, which seems excessive. 页面包含五十多个图像，这似乎过多。 Retina accounts for a relatively small proportion of devices. 视网膜在设备中所占的比例相对较小。 SVG, icon fonts, and CSS3 effects can replace many images. SVG，图标字体和CSS3效果可以替换许多图像。There are numerous tools to help reduce file sizes.
有许多 工具可帮助减小文件大小。
The survey also reveals:
调查还显示：
95 HTTP requests are made per page — a drop of a single request from last year. 每页发出95个HTTP请求-比去年减少了一个请求。 Pages contain 862 DOM elements. 页面包含862个DOM元素。 Resources are loaded from sixteen domains with a maximum of 52 requests per domain. 资源从16个域中加载，每个域最多52个请求。The average PageSpeed score is 78 out of 100 — which is surprisingly good, given the bloat.
PageSpeed的平均得分是78分(满分100)-考虑到膨胀，这是令人惊讶的好。
46% of pages use Google libraries. 46％的页面使用Google库。 47% of pages use custom fonts. 47％的页面使用自定义字体。 79% of responses are compressed (gzip’d). 79％的响应被压缩(gzip'd)。 14% of pages are loaded over HTTPS. 通过HTTPS加载了14％的页面。 20% of pages use localStorage. 20％的页面使用localStorage。 65% of pages use iframes (mostly videos and advertising). 65％的网页使用iframe(主要是视频和广告)。 74% of pages use at least one redirect — which seems high. 74％的页面至少使用一个重定向-似乎很高。A 15% increase is less extravagant than the 32% rise in 2013 and the 30% rise in 2012, but it’s still too much. Has your bandwidth increased more than 15% in the past twelve months? A third of web users now use mobile devices — will they appreciate the additional weight?
15％的增长比2013年的32％和2012年的30％增长要奢侈些，但仍然太高了。 在过去的十二个月中，您的带宽增加了15％以上吗？ 现在，三分之一的网络用户使用移动设备 -他们会欣赏额外的重量吗？
Let’s put this into context for website owners. Bloated pages adversely affect your profitability:
让我们将其与网站所有者联系起来。 膨胀的页面会对您的盈利能力产生不利影响：
Users have a slower experience. It doesn’t matter how great your site looks — people will not wait.
用户体验较慢。 您的网站看起来有多好都没关系- 人们不会等待 。
There’s little point creating a site that works on mobile devices when your pages are 2Mb. Responsive Web Design != a responsive website. Are you losing up to a third of potential customers? 当页面为2Mb时，创建一个可在移动设备上运行的网站毫无意义。 响应式Web设计！=响应式网站。 您是否失去了多达三分之一的潜在客户？ Google will downgrade your site and harm your search engine optimization efforts (though we’re never sure exactly how much this matters to Google’s algorithm). Google会降级您的网站并损害您的搜索引擎优化工作(尽管我们不确定这对Google的算法有多重要)。 Your hosting costs will increase. 您的托管费用将会增加。 The more code you use, the more likely it will break. Updates and maintenance are more difficult, take longer and cost more. 您使用的代码越多，中断的可能性就越大。 更新和维护更加困难，需要更长的时间并且花费更多。It’s ironic that web developers praise the benefits of cross-device HTML5 apps when a single page is often larger to download and slower than an equivalent native app.
具有讽刺意味的是，当单个页面的下载量通常大于同等的本机应用程序时，Web开发人员会赞扬跨设备HTML5应用程序的优势。
Overweight pages are unnecessary. My primary suspects remain bloated CMS templates and frameworks. They offer a cheaper and quicker development route at the expense of quality, efficiency and performance. Many are packed with features you’ll never use, but removing them can be laborious, tedious, and time-consuming.
超重页面是不必要的。 我的主要嫌疑人仍然是膨胀的CMS模板和框架。 它们以质量，效率和性能为代价提供了更便宜，更快速的开发路线。 许多功能都包含了您永远不会使用的功能，但是删除它们可能很麻烦，乏味且耗时。
We can summarize the problem in one simple word: laziness. Developers are at fault — that’s you and me. We have plenty of excuses:
我们可以用一个简单的词概括这个问题： 懒惰 。 开发人员有错-那就是你和我。 我们有很多借口：
there’s never enough time
没有足够的时间
the client insisted it should be done this way
客户坚持应采用这种方式
the budget/schedule is too tight
预算/时间表太紧
I inherited a shoddy system
我继承了伪劣系统
I don’t have the tools
我没有工具
Whether it’s technical boundaries or a failure to explain issues, it’s still laziness. We work at the coal face; the final decisions are ours alone. Why create a badly-optimized site when many bloat-blasting solutions are simple and take minutes to implement?
无论是技术界限还是无法解释问题，仍然是懒惰。 我们在煤矿工作。 最终决定权是我们的。 当许多爆破解决方案很简单并且需要几分钟的实施时间时，为什么要创建一个优化不佳的站点？
Clients rarely appreciate the efficiency gains we make but they don’t understand anything we do. We are the experts, and minimizing page weight is an essential part of the job. Do it. It’s easier to beg for forgiveness than to ask for permission.
客户很少欣赏我们所获得的效率提高，但他们不了解我们所做的任何事情。 我们是专家，使页面重量最小是这项工作的重要组成部分。 做吧 乞求原谅比寻求许可要容易。
</rant></soapbox>
</ rant> </ soapbox>
Are you concerned by the web obesity problem? Are you pleased the scale of increases has dropped? Do you or fellow developers struggle to implement optimization techniques or to explain them to clients? Do you think there are other causes? Is Craig being too simplistic and shouty?!
您是否担心网络肥胖问题？ 您是否满意增加的规模下降了？ 您或开发人员是否在努力实施优化技术或向客户解释这些技术？ 您认为还有其他原因吗？ 克雷格(Craig)太过简单和高喊吗？
翻译自: https://www.sitepoint.com/average-page-weight-increases-15-2014/
2014毕业生平均工资
相关资源：jdk-8u281-windows-x64.exe