然我们生活在一个宽带无处不在、4/5G 几乎全覆盖的时代,但网站加载缓慢还是常态,就算我们打开一个以文本为中心的新闻网站,都可能需要至少 30 秒才能开始阅读。毕竟在内容膨胀时代,一张照片就能轻易超过 1MB 大小,许多网站为了显示几段文本,还会单独加载至少 10MB 的 JS 和自定义字体。
对此,对优化和极简主义充满热情的资深 Web 开发 Nathaniel 告诉我们,你应该让你的网页尽力控制在 14KB 以内,而且即使对于以富媒体为中心的网站,这条 14KB 的规则可能仍然值得遵循。如果 14KB 不足以用于最终布局,则需要优先考虑“首屏”字节,可以用发送给访问者的前 14KB 数据来渲染一些有用的东西,减少用户还没有开始阅读就流失掉的机会。
网页越小,加载速度就越快——这一点都不奇怪。
但令人感到惊讶的是,14KB 网页的加载速度比 15KB 要快得多——可能快 612 毫秒——而 15KB 和 16KB 网页之间的加载速度差异微乎其微。
这是 TCP 慢启动算法导致的。本文将介绍这个算法、它的原理以及为什么你应该关注它。但首先我们需要快速过一遍一些基础知识。
传输控制协议(Transmission Control Protocol,TCP)是一种使用 IP 协议可靠地发送数据包的方法——有时被称为 TCP/IP。
当浏览器向你的网站(或图像或样式表)发出请求时,它会使用 HTTP 请求。HTTP 建立在 TCP 之上,一个 HTTP 请求通常由许多 TCP 数据包组成。IP 只是一个将数据包从互联网上的一个位置发送到另一个位置的系统。IP 没有检查数据包是否成功到达目的地的方法。
对于网站来说,确保所有的数据到达请求端是非常关键的,否则我们可能会因为丢失数据包无法获得完整的网页。但在网络的其他应用场景中,这一点并不那么重要——比如流媒体直播视频。
TCP 是 IP 的扩展,浏览器和网站服务器通过它告诉对方哪些数据包已经成功到达。
服务器发送一些数据包,然后等待浏览器已经收到数据包的响应(这叫确认或 ACK),然后它继续发送更多的数据包——或者如果它没有收到 ACK,将再次发送相同的数据包。
TCP 慢启动是一种算法,服务器用它来确定一次可以发送多少数据包。
当浏览器第一次连接到服务器时,服务器无法知道它们之间的带宽是多少。带宽是指在单位时间内网络可以传输的数据量。通常以比特/秒(b/s)为单位。我们可以用管道来作类比——把带宽想象成每秒从管道流出多少水。
服务器不知道网络连接可以处理多少数据——所以它先发送少量且安全的数据——通常是 10 个 TCP 数据包。如果这些数据包成功地到达网站访问者,他们的计算机返回确认(ACK),表示数据包已经被收到了。然后,服务器发送更多的数据包,但这一次它将数据包的数量增加了一倍。
这个过程会不断重复,直到数据包丢失,服务器没有收到 ACK。(此时,服务器会继续发送数据包,但速度较慢)。
这就是 TCP 慢启动的要点——在现实当中,虽然算法各不相同,但这是它的基本原理。
大多数 Web 服务器的 TCP 慢启动算法都是从发送 10 个 TCP 数据包开始的。
TCP 数据包最大长度为 1500 字节。这个最大值不是由 TCP 规范设置的,它来自于以太网标准。
每个 TCP 数据包的标头占了 40 个字节,其中 16 个字节用于 IP,另外 24 个字节用于 TCP。
这样每个 TCP 数据包还剩下 1460 个字节。10 x 1460 = 14600 字节,或大约 14KB!
因此,如果你能把网站的网页——或网页的关键部分——压缩到 14KB,就可以为访问者节省大量的时间——他们和网站服务器之间的往返时间。
一个数据往返能有多糟糕?但人们非常没有耐心——一个数据往返可能会出奇地长,具体多长取决于延迟……延迟是指数据包从源传输到目的地所花费的时间。如果带宽是每秒钟可以通过管道的水的数量,那么延迟就是一滴水进入管道后从另一端流出所花费的时间。
下面是一个关于延迟有多糟糕的例子。
卫星网络是由环绕地球轨道的卫星提供的,在人烟稀少的地区、石油钻井平台、游轮以及飞机上,人们可以使用这种网络。
为了说明这种糟糕的延迟,我们想象一群在石油钻井平台工作的兄弟把骰子忘在了家里,他们需要通过 missingdice.com(少于 14KB)来玩《龙与地下城》游戏。
首先,他们中的一个用手机发出一个网页请求……
手机将请求发送到钻井平台的 WiFi 路由器,路由器将数据发送给平台上的卫星天线,我们假设这可能需要 1 毫秒时间。
然后,卫星天线将数据发送到地球轨道上方的卫星。
通常,这是通过在地球表面上方 35786 公里处运行的轨道卫星实现的。光速为 299792458 米/秒,所以信息从地球发送到卫星需要 120 毫秒。然后,卫星将信息传回地面接收站,这又需要 120 毫秒。
然后,地面站必须将请求发送到位于地球任意位置的服务器(当光通过光纤电缆传输时,速度会降至每秒 200000000 米)。如果地面站和服务器之间的距离等于纽约到伦敦之间的距离,那么大约需要 28 毫秒,如果地面站和服务器之间的距离等于纽约到悉尼之间的距离,则需要 80 毫秒——所以我们姑且定一个 60 毫秒的数字(这个数字便于计算)。
然后,服务器需要处理请求,这可能需要 10 毫秒,然后服务器再次将它发送出去。
回到地面站,进入太空,回到卫星天线,然后回到无线路由器,再到手机上。
手机 -> WiFi 路由器 ->卫星天线 ->卫星 -> 地面站 -> 服务器 -> 地面站 -> 卫星 -> 卫星天线 -> WiFi 路由器 -> 手机
如果我们算一下,就是 10 + ( 1 + 120 + 120 + 60 ) x 2 = 612 毫秒。
这是每次往返额外的 612 毫秒——也许这看起来不是很长时间,但你的网站可能只是为了获取第一个资源就需要许多个往返。
另外,HTTPS 在完成第一个往返之前需要额外的两次往返——这使延迟达到了 1836 毫秒!
卫星网络似乎是一个极端的例子——我选择它作为例子是因为它能够充分说明了网络延迟这个问题——但对于生活在陆地上的人来说,延迟可能比这更糟糕,原因有很多。
不稳定的网络连接也会导致数据包丢失——导致需要另一个往返来获取丢失的数据包。
了解了 14KB 法则,接下来可以做些什么
当然,你应该让你的网页尽可能的小——你爱你的访客,你希望他们开心。将每个页面的大小控制在 14KB 以内是一个不错的主意。
这 14KB 可以是压缩数据——所以实际上可以对应大约 50KB 的未压缩数据——这已经非常慷慨了。要知道,阿波罗 11 的制导计算机只有 72KB 内存。
去掉自动播放的视频、弹出窗口、Cookie、Cookie 横幅、社交网络按钮、跟踪脚本、JavaScript 和 CSS 框架,以及所有其他人们不喜欢的垃圾——你可能就能实现 14KB 法则。
假设你已经尽力将所有内容控制在 14KB 以内,但仍然做不到——但 14KB 法则仍然很有用。
你可以用发送给访问者的前 14KB 数据来渲染一些有用的东西——例如一些关键的 CSS、JS 和解释如何使用你的应用程序的前几段文本。
需要注意的是,14KB 法则包含了 HTTP 标头——这些是未压缩的(即使是 HTTP/2 的第一个响应),也包含图片,所以你应该只加载在页面上方的内容,并保持它们最小,或者使用占位符,让访问者知道他们在等待一些更好的内容。
14KB 法则更像是一种经验之谈,而不是计算的基本法则。
有一种观点认为,在使用 HTTP/2 时,14KB 法则不再适用。我已经读了所有我能读到的关于这个问题的东西,但我还没有看到任何证据表明使用 HTTP/2 的服务器已经停止使用 TCP 慢启动(从 10 个数据包开始)。
与 HTTP/2 类似,有一种观点认为 HTTP/3 和 QUIC 将废除 14KB 法则——事实并非如此。实际上,QUIC 仍然建议使用 14KB 法则。
原文链接:
https://endtimes.dev/why-your-website-should-be-under-14kb-in-size/
有一个最佳的屏幕尺寸可以设计。网站应在不同的浏览器和平台上以所有屏幕分辨率快速响应地进行转换。无障碍。移动友好。首先为您的访客设计。从360×640到1920×1080的设计。
它仍然应该看起来不错,并且在所有尺寸下都可以正常工作,现在我们的建议是建设一个自适应/响应式网站。
针对特定屏幕尺寸优化页面布局的三个主要标准是:
可用性准则还建议您考虑所有大小的所有三个条件。检查浏览器窗口的屏幕分辨率为360×640到1920×1080。
在整个分辨率范围内,您的网页在所有条件上的得分都应该很高。
您的页面也应该以更大或更小的尺寸工作,尽管这种极端情况不那么重要。
尽管此类用户当然应该能够访问您的网站,但为他们提供小于设计的外观有时是可以接受的折衷方案。
2020年的前6个月中,对451,027个访客进行了访客分析:
屏幕分辨率测试用户数11920×108088,378(19.53%)21366×76867,912(15.01%)31440×90043,687(9.65%)41536×86432,872(7.26%)52560×144025,954(5.73%)61680×105020,068(4.43%)71280×72015,138(3.34%)81280×80014,007(3.09%)9360×64011,085(2.45%)101600×90010,193(2.25%)
响应式Web设计:在相同的URL上提供相同的HTML代码,而不管用户的设备(例如,台式机,平板电脑,移动设备,非可视浏览器)如何,但是可以根据屏幕大小来不同地呈现显示。 百度建议使用响应式Web设计,因为它是最容易实现和维护的设计模式。
在当今世界,许多人正在使用手持设备(平板电脑和智能手机)浏览网页,而响应式网站设计(RWD)已经成为解决屏幕尺寸挑战的极有可能的解决方案。
此方法不再使用固定宽度的网站,而是使用CSS样式表中的“媒体查询”来创建一个网站,该网站在大小上响应手持设备的不同视口以及人们使用的较小屏幕。
因此,无论人们使用什么设备来查看您的网站,您都可以为他们提供最完整的体验。
如果您想为高竞争力的关键词在百度获得高排名,您就需要一个适合移动设备的网站。
网站对移动设备的友好程度如何影响各种设备对网站的排名效果。如果您为小型企业创建网站,您会知道他们想要一个在百度自然搜索中表现良好的网站。
目前从本质上讲,这意味着网站设计具有响应性并且对移动设备友好,尤其是对于百度而言。
作为参考,以下是最近(2020年)记录的当前全球顶级屏幕分辨率的列表:
你不能。不可能将网站设计成在每个浏览器,平台和屏幕分辨率下看起来都一样,所以请避免尝试。
您可以选择不带表格的流畅布局来进行设计,其宽度百分比可以扩展和收缩以适合访问者浏览器的设置,或者您可以考虑研究能够实现相同效果的响应式设计解决方案。
搜索引擎偏爱响应式设计,这对于采用它的人来说是个好消息。移动技术正在兴起-因此,如果要开发一个新网站-您必须从一开始就考虑您的网站对移动设备的友好程度。
在实际编写代码时,我们的目标是使事情简单。从经验中我们知道的是, 对于您而言,确定您的受众及其使用的设备,并从整体上构建适合该受众的网站至关重要,受众也包括搜索引擎。
好吧,那不是理想的。实际上,它从未如此。
追溯到今天-一些人使用网站的纯文本版本为不支持其网站元素的用户/浏览器生成内容-试图(通常是徒劳的)使他们的内容更易于访问。
W3C甚至曾经推荐它,我们认为如果其他所有方法都失败了:
为访问者目的而向访问者传递一个URL始终是理想的选择,并且如果您正在考虑创建网站的“移动”版本,则在传递移动或智能手机内容时没有任何区别。
百度可能会在不久的将来对您的移动体验做出主要评价-因此,我们所有人都确实需要意识到我们可能很快会在百度的SERP中看到巨大的变化。
当百度作为“访问者”时,由于搜索引擎的典型URL挑战,通常只提供一个URL甚至更为重要-在前一段时间实施规范链接元素之前就是这种情况。
因此,理想的情况是始终提供一个URL。
百度在这方面给出了建议:“如果您具有“智能手机”内容(我们将其视为普通的Web内容,因为它通常是普通的HTML页面,只是在布局上进行了调整以显示较小的内容),则可以使用rel = canonical指向您的桌面版本。这有助于我们专注于网络搜索的桌面版本。当用户使用智能手机访问该桌面版本时,您可以将他们重定向到移动版本。无论URL结构如何,此方法均有效,因此您无需为智能手机移动网站使用子域/子目录。 然而,更好的方法是使用相同的URL并显示内容的适当版本而无需重定向。”
百度还提供了以下提示,以检查您的网站是否准备好使用移动优先索引,但是从本质上讲,如果您正在为网站使用响应式网页设计模板,则此更改的问题应该很小:
过去的网页用户通常不需要滚动,但多年来,这种情况已经改变。
因此,在设计时,应考虑如果用户只滚动一个完整屏幕或两个屏幕,可以看到多少内容。超过五个屏幕的长度可能表示您页面上的内容过多。当然,用户希望等待更短的时间来查看更全面的内容。
滚动和初始可见性显然都取决于屏幕尺寸:较大的屏幕在屏幕上方会显示更多内容,并且需要较少的滚动。
不一定,但是有可能。
与百度优化有关的许多事情–建立一个适合移动设备的网站或多或少可以确保您保持已经获得的访问量,并不一定能为您提供来自百度的更多免费访问量。
百度及其用户再次提高了质量标准,如果您想在更具竞争力的SERP中竞争,这是小企业克服困难的又一个障碍。
从长远来看,这种移动转化仅对您的用户来说是一件好事,但从短期来看,对小型企业的转化率不会产生什么影响,因为通过移动设备获得的转化率通常低于桌面。
百度表示,这种适用于移动设备的算法对SERP的影响更大,随着时间的流逝,我们将发现更多信息。
百度站长工具
您应该能够在百度站长工具中跟踪移动设备错误,并且如果您的网站配置正确,错误会随着时间的流逝而消失。
体查询
响应式网页是这几年很流行的网页风格之一,他能够以一套网页代码,面对不同的条件,例如改变浏览器的宽度,手机横竖屏,作出不同的样式调整。
一套代码走天下
最出名的响应式框架是Bootstrap,来自Twitter。也是每个刚入门前端开发师必学的框架,利用这个框架可以很轻松实现响应式效果。
面对不同的浏览器宽度,作出界面调整
要实现响应式,关键在于使用媒体查询 Media!
@media (媒体特性)and (媒体特性) {你的样式}
看起来好像很复杂,先看完整的代码
@media (max-width:480px){
body{background-color:green}
}
上面这句话的意思,浏览器的宽度小于或等于480px时,背景颜色是绿色。
再来多一个,如下
@media (min-width:481px){
body{background-color:red}
}
上面这句话的意思,浏览器的宽度大于或等于481px时,背景颜色是红色。
媒体特性
媒体特性就是依据什么样的条件来进行更改样式,是根据屏幕宽度大小、还是横竖屏呢。这些条件都是官方定的,非常多。但实际上,真正有用的就是 min-width和max-width,根据浏览器宽度来设定不同的样式。
这里会很容易混淆min-width和max-width的意义。min-width表示大于等于,max-width表示小于等于。
@media (max-width: 500px) {
/** 窗口宽度小于等于500像素的样式 **/
}
@media (min-width: 800px) {
/** 窗口宽度大于等于800像素的样式 **/
}
当有多个媒体特性时,用and连接,就可以形成一个区间范围
@media (min-width: 600px) and (max-width: 700px) {
/** 窗口宽度在600-700像素的样式 **/
}
这就是他最基本的用法,凡是有两面性,下面来说说他的优缺点。
优点
(1)面对不同分辨率设备灵活性强
(2)能够快捷解决多设备显示适应问题
缺点
(1)兼容各种设备工作量大,效率低下
(2)代码累赘,会出现隐藏无用的元素,加载时间加长
全局布局
下面这种响应式布局最为常见,通过媒体查询定义不同的样式,让其能够适应手机浏览器和桌面浏览器:
1、电脑端大屏幕下,网页元素全部展示
电脑端样式
2、手机端下,因为屏幕有限,只能让主体内容呈现出来,其余部分隐藏起来,并且让字体缩小。
手机端样式
栅格布局
一提起响应式,绝对离不开强大的栅格布局,根据浏览器的宽度,设置容器不同的列宽。
<div class="row">
<div class="col-xs-12 col-sm-6 col-md-8"></div>
<div class="col-xs-12 col-sm-6 col-md-8"></div>
</div>
只需要按照填写bootstrap参数,即可匹配不同的宽度
栅格布局的原理其实也是利用了媒体查询,这样你就可以自定义一份自己的栅格布局。
部分源代码
*请认真填写需求信息,我们会在24小时内与您取得联系。