读一开始我们的H5页面秒开率只有30%左右,现在我们的H5页面秒开率达到了 75%。这中间巨大的差异究竟有哪些黑科技在里面?我们为什么要做H5页面的秒开优化?我们的秒开指标是如何统计的?客户端和H5是怎么配合做到 1+1>2的?监控是如何发现H5页面可优化项的?我们又通过监控发现了哪些可优化的问题呢?
H5秒开优化是一个老生常谈的问题,本文将逐步介绍如何通过客户端 + H5 的优化手段(1+1>2)把秒开从 30% 提升到 75% ?后续接口预请求、客户端预渲染以及预加载2.0上线后还会再次助力指标提升。
为什么要做优化?
Global Web Performance Matters for ecommerce 的报告中指出:
整体系统架构图:
首先讲一下得物用来衡量秒开的指标 FMP,那为什么不选择 FCP 或者 LCP 呢?FCP 只有要渲染就会触发,LCP 兼容性不佳,得物希望站在用户的角度来衡量秒开这件事情,用户从点击打开一个WebView到首屏内容完整的呈现出来的时间点就是得物定义的FMP触发时机。
指标清楚了之后,再来看一下完整的 FMP 包含哪些耗时。
接下来将分为两大部分进行介绍,客户端优化部分和H5 优化部分。
通过 HTML 预加载、HTML 预请求、离线包、接口预请求、链接保活、预渲染等手段提升页面首屏打开速度,其中预加载、预请求、离线包分别可提升10%左右的秒开。
通过配置由客户端提前下载好HTML主文档,当用户访问时直接使用已经下载好的HTML文档,以此减少HTML网络请求时间,从而提升网页打开速度。
前人栽树后人乘凉,得物App有很多的资源位,banner、金刚位、中通位等,这些位置显示什么内容,早就已经是智能推荐算法产出的了,那么就可以直接指定这些资源位进行预加载。
页面被预加载之后,总不能一直不更新吧?那么什么时候更新页面的缓存呢?
被现实打脸:
但是在后面的灰度过程中被现实狠狠的教育了一顿,发现有些SSR的页面会涉及到状态的变更,比如说:领劵场景。这些状态都是经过SSR服务渲染好的,用户在进入页面时还没有领劵,这个时候去更新HTML文档,实属更新了个寂寞,在用户领劵之后关闭页面再次进入,发现页面中的状态仍是让用户领劵,点击领劵又告诉人家你已经领过了。
改进措施
至此问题也解决了,工程师的任务结束了吗?如果你认为功能做上去就算结束,那么此时此刻请你一定要转变思维,想一想我们的目标是什么?我们的目标是「提升秒开」,预加载只是一种提升秒开的手段,但是在功能做上去之后并不知道这个功能带来了多少秒开的收益,因此在把功能开发完成上线之后,就要开始关注上线之后的结果,来看看预加载的性能表现如何。从下图可以看到,预加载开启状态下可提升10%以上的秒开率。
(1)SSR服务扩容
要解决服务器压力问题,很自然就会想到增加机器,于是我们对SSR机器数量做了一次扩容,将机器数量提升了一倍,这个时候继续尝试扩大预加载的用户数量,但是仍然无法抗住这么大的QPS,而且此时还引发了第二个问题,算法部门的服务器发出了告警,于是放量计划又一次遇到了阻碍。
(2)破局者 CDN
利用CDN 服务器的缓存能力既可以减轻 SSR 服务器的压力又可以减少后端服务链路的压力,这么好的东西为什么不用呢?这里留个悬念,后面将H5优化部分会详细介绍。
(3)客户端配合改造
支持针对CDN域名进行全部开放预加载能力,针对非CDN域名保持原有放量比例。
在这个过程中还分析了页面的流量占比,发现开屏广告来源的页面流量占比也很高,那么是不是可以把开屏广告的HTML文档内容也给预加载下来呢?
开屏页面预加载策略
既然可以提前下载好HTML,那是不是可以更进一步,提前把页面内的资源加载好,这样在打开一个页面的时候可以减少大部分的网络请求从而更快速的把内容呈现给用户。这里还需要考虑如何跟下面讲到的离线包进行协作。
在WebView初始化同时,去请求HTML主文档,等待HTML文档下载完成 且 WebView初始成功后渲染,减少用户等待时间,客户端请求成功后,WebView加载本地 HTML,并保存以供下次使用。预请求HTML开启状态下可提升8%左右的秒开。
预请求 VS 预加载
本质上HTML预加载和HTML预请求的区别就是下载HTML文档的时机不同, 预加载是在App启动后用户无任何操作的情况下就会去下载,但是预请求只会在用户单击打开H5页面的时候才会去下载。如果用户是第二次打开某个H5页面,此时发现本地有已经下载好的HTML且尚未过期就会直接使用,这个时候的行为表现就跟预加载的功能是一致的了。
上线之后发现预请求只提升了2%左右的秒开,经过分析发现问题:
在本地用低端机对整个秒开耗时链路进行了分析,为什么要用低端机分析呢?低端机有个好处,天然的加上了慢放功能,可以最大程度发现问题。
从图中可以看出h5 页面加载之前 耗时 分布在 activityStart() 函数,该函数 包含了 onCreateView ,其中耗时最长是 布局填充 inflate(),因为 WebView 对象是提前创建好的,直接从对象池中取出的,所以耗时主要在 初始化过程,WebView 自身的初始化 WebViewChromiumFactoryProvider. startYourEngines (耗时 87 us,不到 1 ms),耗时还有 WebView 的一些其他初始化,jockey 的初始化 等等。
而秒开的计算是包含了 View 初始化到 WebVIew url 加载 的耗时,从而发现了优化点,可以将Webview loadUrl 前置,h5 页面加载 与 原生布局填充并行执行。在 onCreateView 时,创建 FrameLayout 进行返回,执行 WebView loadUrl 之后,主线程开始 对布局进行 inflate,布局加载成功后,将其 addView 到 FrameLayout 中,减少了 loadUrl 的阻塞时长。中高端机型有 15ms 左右优化,低端机型有 30 ~ 50 ms 优化 效果。
预请求HTML时机是在进入到 native 页面中,这个时间点距离用户单击事件已经过去100ms,那么是否可以将下载HTML的时机提前呢?经过一番探索,最终选择在路由阶段进行拦截,既可以统一收口而且距离用户点击的时间间隔可以忽略不计。通过这种方式将下载HTML时机提前了平均80ms+。
此时的流程变成了下面这样。
可能有的同学会问了,为什么不在用户点击的时候去下载呢?从用户点击到路由肯定还是有耗时的。
在上述问题解决后,将缓存时间修改为1天,发现预请求HTML开启状态下可提升8%左右的秒开,已经和预加载的效果相差不大了。
通过提前将H5页面内所需的css、js等资源聚合在一个压缩包内,由客户端在App启动后进行下载解压缩,在后续访问H5页面时,匹配是否有本地离线资源,从而加速页面访问速度。
资源拦截这块安卓这边实现比较简单,WebView支持 shouldInterceptRequest, 可以在该方法内检测是否需要进行资源拦截,需要的话返回 WebResourceResponse 对象,不需要直接返回 null。
但是在iOS 这边遇到了一些困难,调研了以下方案:
NSURLProtocol 拦截方式,使用WKBrowsingContextController和registerSchemeForCustomProtocol。通过反射的方式拿到了私有的 class/selector。通过把注册把 http 和 https 请求交给 NSURLProtocol 处理。通过这种方式确实可以拦截请求,但是发现post请求的body会出现丢失的问题。而且NSURLProtocol一经注册就是全局开启。我们希望他只会拦截接入了离线包的页面,但是没有办法控制他,他会拦截所有页面的请求,包括第三方合作页面,显然这是无法接受的。
在iOS 11及以上系统中, 拥有了加载自定义资源的API:WKURLSchemeHandler。
可以修改当前页面url为自定义 scheme 协议,比如:https://fast.dewu.com 修改为 duapp://fast.dewu.com 然后在客户端内注册该 scheme,前端配合修改页面内所有的资源请求未自适应协议,如:src="//fast.dewu.com/xxx" 就可以实现拦截。但是在测试过程中发现,接口为了安全起见只允许白名单内的域名发起跨域请求,且无法配置多个域名,导致该方案无法继续进行。
仍然是使用 WKURLSchemeHandler 然后通过 hook WKWebview 的 handlesURLScheme 方法来支持 http 和 https 请求的代理。通过这种方式虽然可以拦截请求了,但是遇到了以下问题:
(1)body丢失问题
不过在 iOS 11.3 之后对这种情况做了修复处理,只有 blob 类型的数据会丢失。需要由JS来代理 fetch 和 XMLHttpRequest 的行为,在请求发起时将 body 内容通过 JSBridge 告知 native,并将请求交给客户端进行发起,客户端在请求完成后 callback js 方法。
(2)Cookie 丢失、无法使用问题
通过代理 document.cookie 赋值和取值动作,交由客户端来进行管理,但是这里需要额外注意一点,需要做好跨域校验,防止恶意页面对cookie进行修改。
至此功能开发完成上线,先来一组线上收益数据,安卓开启离线情况有有10%左右的收益,但是iOS开启离线的反而秒开率更低。经过修复处理后iOS也可提升10%以上的秒开。
安卓和iOS实现差异
经过分析对比发现,安卓的拦截动作比较轻,可以判断是否需要拦截,不需要拦截可以交给WebView自己去请求。
但是iOS这边一旦页面开启拦截后,页面中所有的http和https请求都会被拦截掉,由客户端发起请求进行响应,无法将请求交还给WebView自己去发起。
iOS 缓存问题修复
页面中的资源经过客户端请求代理后原本第二次打开WebView本身会使用缓存的内存,现在缓存也失效了,于是只能在客户端内实现了一套缓存机制。
从下图可以看到离线包的下载错误率在 6% 左右浮动,这么高的下载错误率肯定是无法接受的, 经过一系列优化手段,把离线包下载错误率从6%左右浮动下降至 0.3%左右浮动。
先来看下优化前的流程图和问题点。
通过埋点发现大量 unknown host 、网络请求失败、网络连接断开的情况。分析代码发现下载未做队列控制,会同时并发下载多个离线包,从而导致多个下载任务争抢资源的情况。针对发现的问题点做出了以下优化:
下面是优化之后的流程图:
针对离线资源是直接存储在磁盘上的,每次访问都会有磁盘IO耗时,经过在低端机器上做测试发现这个耗时会在 0 - 10ms 之间进行波动,后面会把内存合理的利用起来,通过设置内存上限,文件数量上限,甚至是文件类型,并通过 LRU 策略进行内存文件的淘汰更新。
通过客户端发起H5页面首屏接口请求,远比等待客户端页面初始化、下载HTML、JS下载执行的时机更提前,从而节省用户的首屏等待时间。在本地测试过程中发现接口预请求可提前100+ms,用户也就可以更快的看到内容。
客户端会在App启动后获取配置,保存支持预请求的页面地址及对应的接口信息,在用户打开WebView时,会并行发起对应预请求的接口,并保存结果。当JS执行开始获取首屏数据时,会先询问客户端是否已经存有对应的响应数据,如果此时已经拿到数据则无需发起请求,否则 js 也会发起接口请求并开启竞速模式。以下是整体流程图:
那么客户端怎么知道这个页面需要请求什么接口呢?以及接口的参数是什么呢?那自然少不了配置平台,它支持以下功能:
首先即使是在 SSR 的情况下,首屏内容中仍然可能有部分组件是骨架直出的,需要等待页面渲染执行时才会去请求数据,另外还有一部分页面是SPA的。针对这两种情况都能做到很好的补充。
开启后DNS 90分位耗时从80ms降至0ms,TCP建连90分位耗时从65ms分位耗时降为0,DNS平均耗时从55ms降为4.3ms,TCP建连平均耗时从30ms降为2.5ms。
通过上图可以看到一个网络请求在经过DNS解析耗时、TCP建连耗时、SSL建连耗时阶段之后才能把请求发出去,那么是否可以节省这段时间的耗时呢?
客户端常用的网络请求框架如OkHttp等,都能完整支持http1.1与HTTP2的功能,也就支持连接复用。了解了这个连接复用机制优势,那就可以利用起来,比如在APP开屏等待的时候,就预先建立关键域名的连接,这样进入相应页面后可以更快的获取到网络请求结果,给予用户更好体验。在网络环境偏差的情况下,这种预连接理论上会有更好的效果。
可以通过对域名链接提前发起一个HEAD请求从而建立链接,网络框架会自动将连接放入连接池。并在默认无操作5分钟后进行释放,在五分钟内重复执行上述动作即可一直保持链接。
另外这里需要注意下连接池的数量问题,如果连接池的数据太小,但是域名比较多的话,通过预建连保持的链接很容易就会被释放掉,这就需要通过域名收敛或者调大连接池的数量来进行优化。
那预建连会不会增加服务器的压力呢?这个肯定是会的,首先会针对预建连功能本身就行灰度策略,在HTML页面通过CDN托管后,直接针对 cdn 域名进行全量开启,从而不用担心 cdn 域名扛不住压力。
来看一下线上效果,通过下图可以看到在开启后DNS 90分位耗时从80ms降至0ms,TCP建连90分位耗时从65ms分位耗时降为0,DNS平均耗时从55ms降为4.3ms,TCP建连平均耗时从30ms降为2.5ms。
客户端提前通过WebView将页面渲染好,等待用户访问时,可直接展示。从而达到瞬开效果。但是这种功能肯定不能对所有的页面进行开放,而且存在一定的弊端。
下图【开学季】是业务上已经进行预渲染的H5页面,可以看到在打开【开学季】页面时,页面已经渲染完毕,丝毫没有等待过程。
后面计划把这种能力放大到通用的webview上,针对大促以及PV量高的页面进行开放。
SSR服务端渲染(英语:server side render)一般情况下,一个H5页面的数据渲染完全由客户端来完成,先通过AJAX请求到页面数据并把相应的数据填充到模板,形成完整的页面来呈现给用户。而服务端渲染把数据的请求和模板的填充放在了服务端,并把渲染的完整的页面返回给客户端。
SSR对于秒开有平均15%的提升,既然是服务端渲染,就会对服务器造成压力,尤其是在预加载HTML功能开启后,那得物是如何解决的呢?
通过这么多优化手段仍然无法满足预加载的需求,并且通过分析发现网络阶段耗时较长,最终还是搬出了CDN这个大杀器,一直没上CDN的原因有很多,主要有以下几方面:
(1)得物的页面是千人千面的每个人看到的内容都不同
通过上述优化4即可解决,将原本SSR渲染的内容修改CSR,由于已经上了CDN了,后续计划将这部分内容再次修改回SSR,这样用户可以更快的看到商品而不是骨架,然后通过 CSR 的方式来更新内容。
(2)页面状态变更,无法及时更新缓存
这个问题在上述客户端预加载优化部分已经有解决方案了,可以通过在页面打开后针对有需要的组件再次请求接口刷新数据以确保数据的准确性,但是这部分工作量也是比较大的,梳理出来的需要刷新状态的组件就有30+,而且之后开发的组件都需要考虑状态更新的事情。
(3)HTML模板内容变更无法及时更新
引起模板内容变更的地方有两处,第一个场景就是在搭建器场景下,运营可以动态修改模板内容导致页面结构变更(低频次),第二个场景是项目发版后模板内容需要更新(高频)。
这个问题可以通过在感知到内容变更时自动调用CDN服务商的刷新缓存接口来更新CDN缓存内容。
通过puppeteer将SPA页面渲染出来并将HTML文档进行保存,配合上述页面刷新策略,并将HTML通过CDN进行托管,让你的 SPA 页面 像 SSR 一样丝滑。
主要实现方案是通过基于webpack的插件prerender-spa-plugin,并配置需要预渲染的路由,这样经过打包之后就会产出对应路由的页面。方案本身是通用的,但是每接入一个页面都需要人工check。
众所周知 css 加载会阻塞HTML渲染,最终将首屏公共css从118kb缩减至38kb,下图通过 chrome 模拟弱网环境下的SSR页面加载时序图。从图中可以看出 styles.fb201fce.chunk.css 下载耗时 18s,阻塞了页面的渲染,HTML 主文档耗时 2.38s 就已经下载完成了,但是实际渲染时间却是在 20s 之后。
优化思路也比较单间,将首屏所需要的css 文件通过内联方式内嵌到HTML中,由SSR服务一并返回,并对css文件进行拆分,按需加载。
思路有了,接下来就看怎么去实现了,最初尝试了MiniCssExtractPlugin 插件他可以把css分成单独的文件,并且每一个js会对应生成一个css文件,但是他需要建立在webpack5之上,然而项目中使用的next版本是9.5,于是就想着升级到最新版next12,升级后发现,在构建中其他包各种报错,发现有些包并不支持最新的next12,在尝试一天的修复之后,仍未解决,且升级到最新版不确定是否会引发其他稳定性问题,暂且搁置寻找其他方法。
经过不懈的努力,通过阅读 next 源码发现了端倪,发现在打包时将所有的公共css通过 splitChunks 进行分组,由于项目中组件都是动态引入的,这里直接在 next.config.js 中修改webpack打包参数,将 splitChunks.cacheGroups.styles 配置删除,使用默认的 chunks: async 配置,即可实现按需引入。
(1)避免图片src为空
虽然src属性为空字符串,但浏览器仍然会向服务器发起一个HTTP请求,尤其是在SSR服务器压力扛不住的情况下,因此这里需要特别注意一下。
(2)图片压缩以及格式选择
WebP 的优势体现在它具有更优的图像数据压缩算法,能带来更小的图片体积,而且拥有肉眼识别无差异的图像质量;同时具备了无损和有损的压缩模式、Alpha 透明以及动画的特性,在 JPEG 和 PNG 上的转化效果都相当优秀、稳定和统一。
通过向图片服务器传递参数选择合适的分辨率。
(1)打包优化
(2)非关键js、css延迟加载
(3)媒体资源加载优化
(4)其他资源优化
(5)页面渲染优化
(6)代码层面优化
为了帮助开发者更好地衡量和改进前端页面性能,W3C性能小组引入了 Performance API ,其中Navigation Timing API 实现了自动、精准的页面性能打点。得物前端性能监控指标也都是从 Performance API 中获取数据进行上报统计分析的。
SDK 数据采集完毕后,会上报到 阿里云 sls 日志平台,随后通过 flink 实时消费清洗数据后落库至 clickhouse 中,平台后端通过读取 clickhouse 数据并做各种聚合处理后使用。
做优化之前首先要建立监控指标,互联网称之为抓手,没有监控指标的情况下,任你怎么优化,都不知道优化的效果怎么样,更不知道下一步该做什么?以及还有哪些问题没解决。因此优化之前指标先行,当然一定要指标的准确性。
指标大盘主要包含以下功能:
在正常情况下,完成上述的优化措施后用户基本是可以秒开 H5 页面的了。但异常情况总是会有的,用户的网络环境和系统环境千差万别,甚至 WebView 也可能发生内部崩溃。当发生问题时,用户看到的可能就直接只是一个白屏页面了,所以进一步的优化手段就是需要去检测是否发生白屏以及相应的应对措施。
检测白屏最直观的方案就是对 WebView 进行截图,遍历截图的像素点的颜色值,如果非纯色的颜色点超过一定的阈值,就可以认为不是白屏。首先获取包含 WebView 视图的 Bitmap 对象,然后把截图缩小到指定的分辨率大小如:100*auto,遍历检测图片的像素点,当非纯色的像素点大于 5% 的时候就可以认为是非白屏的情况,但是还有很多列外的情况,我们通过图片识别技术对截图进行分析,可以很好的感知当前是否白屏、是不是在loading、是不是特殊页面等。
白屏是一个重要的指标,我们针对整体白屏率快速拉升、新增白屏页面发出告警通知,便于开发人员及时介入开始排查问题。
主要通过 CDN 未覆盖监控、http请求监控、网络监控(加载失败、耗时异常、传输大小异常)、图片监控(未压缩、分辨率异常)等监控手段发现页面中的潜在问题,同时还提供了问题分析能力,在问题分析页面输入页面url地址即可帮助您发现问题并给出修改建议。
CDN的重要性不言而喻,它可以加速资源访问速度,从而提升用户体验,我们通过对线上埋点数据分析,找出CDN未覆盖的资源列表,从而推动各业务同学优化。
为什么要监控HTTP请求呢?我们先来看一下HTTPS相对于HTTP新增的特点:
那么HTTP就容易被中间人查看到内容,甚至被篡改,既然如此为了我们服务的安全性就需要对现有的http协议统一进行升级改造,那就需要监控去发现。
某些页面秒开率低,那就要分析一下原因,是不是这个页面的接口响应比较慢呢,还是说页面本身有请求比较大的资源?如果发生网络请求失败的情况也要第一时间感知,不能被动等待用户反馈。
包含图片未压缩、图片分辨率异常、图片传输大小大于 300kb 异常、动图资源传输大小大于 1M 异常功能。
上面列出来一堆功能,对于业务的同学可能比较烦恼,我一个页面具体有哪些问题呢?你不能让我去上面的功能里面一个个看,哪个异常是我负责的页面的吧?这个功能本身就行将现有的功能利用起来,通过一个页面path进行聚合分析。
H5异常一直是使用 sentry 进行监控的,但是sentry系统因缺乏同PV、DAU数据的关联性,因此无法衡量产品异常发生后所带来的严重程度。在业务域关联上的缺失导致异常问题无法根据业务域进行划分。用户行为日志也尚未与Native 端侧打通,在问题分析时容易遇到上下文不全的瓶颈。还有一个问题是sentry会有限流措施,当qps较高时会丢弃一部分异常数据。
由于sentry已经可以帮助我们进行一定的问题排查分析能力,我们不打算做sentry同样的功能,而是做sentry不支持的部分,针对上述问题我们设计了以下功能:
虽然目前秒开率已经做到了75%以上,但是同时我们还有一个重要的指标,90分位耗时,致力于提升末尾用户H5页面使用体验,在90分位优化完成后,可能会考虑继续深入优化95分位耗时。
至此我们系统的讲解了背景以及从指标建立到秒开优化上线的全过程,全文分成了三个部分,客户端、H5、以及监控。如果阅读本文对您有所收获,麻烦您动一动发财的小手点个赞吧!如果阅读完还意犹未尽或者有什么问题和想法欢迎留言区评论交流。
最后奉上整体优化脑图:
*文/徐铭
欢迎关注「得物技术」微信公众号,每周一三五晚18:30更新技术干货
要是觉得文章对你有帮助的话,欢迎评论转发点赞~
在自己的页面中嵌入其他页面是一个非常重要的操作,既能丰富自己的页面样式又能增强页面的信息量。
举个例子,如果打算在自己的页面中插入一个视频网站的视频该怎么做呢?
假如我现在自己的页面中嵌入这个视频,
我只需要在视频下侧找到"分享"。
点击之后出现这样的对话框,如图:
通过在我们的页面中粘贴这段通用代码就可以显示这个视频了。
代码如下:
<iframe height=498 width=510 src='http://player.youku.com/embed/XNDQ5Mjg1MTU1Mg==' frameborder=0 'allowfullscreen'></iframe>
下面就写到我们的页面中试试吧。
首先复制"第一个网页.html"文件,改名为"在页面中嵌入页面.html"保存,然后用记事本打开,修改<head></head>标签中的<title>第一个页面</title>编辑为"在页面中嵌入页面"即可,完整代码如下:
<!DOCTYPE HTML>
<html>
<head>
<title>在页面中嵌入页面</title>
</head>
<body>
<iframe height=498 width=510 src='http://player.youku.com/embed/XNDQ5Mjg1MTU1Mg==' frameborder=0 'allowfullscreen'></iframe>
</body>
</html>
页面效果如下:
怎么样,是不是很神奇!
下面我们来分析一下这段代码的含义。
首先要引入一个新标签<iframe>,HTML的使用手册中翻译为"框架",说实话,这么翻译初学者是不知所云的。这个框架元素的主要作用就是在自己的页面中嵌入其他页面。
在<iframe>标签中先指定路径属性即src。这里使用的是单引号,实际上只要是半角符号,单引号和双引号都可以的。
然后设置长宽属性,即width和height,大家可以尝试改变数据看看。
frameborder可以为iframe的窗口指定一个边框,大家可以尝试把0改成1看看。大家注意哈,这里输入30和输入1是一样的,因为这个属性不是定义边框的宽度,而是定义是否显示边框!在编程中叫做布尔值,0代表没有边框,1代表有边框!和我们点灯的开关一样!
如图:多了个边框出来。
最后'allowfullscreen'这个描述非常的奇葩,把它删掉没有任何影响。不晓得是干什么的,主要是也不符合html的语法(也可能是我没见识)。如果有详细了解的小伙伴欢迎留言指教,感激不尽。
下面我们尝试修改一下src属性,给它一个别的路径看看。例如:
<!DOCTYPE HTML>
<html>
<head>
<title>在页面中嵌入页面</title>
</head>
<body>
<iframe height=498 width=510 src='https://www.toutiao.com/i6790673377188119052/'>
</iframe>
</body>
</html>
需要注意的是,修改了src并保存文件之后要把原页面关闭然后重新打开才可以正常显示!
效果如下:
在浏览网页时我们还经常遇到这样的情况,就是有一个独立窗口显示嵌套的页面,上面有个标题,一点击就会跳到那个嵌入的页面上,这个其实很简答,使用一个<a></a>元素即可办到,示例代码如下:
<a href="https://www.toutiao.com/i6790673377188119052/">HTML中的块级元素与内联元素——零基础自学网页制作</a>
<iframe height=498 width=510 src='https://www.toutiao.com/i6790673377188119052/'></iframe>
页面示例如下:
框架元素并没有换行,所有我们可以推测出<iframe>标签实际上是个内联元素,如何让它换行呢?
为<iframe>的style属性中写入display:block即可。这句代码的意思是按照块元素来显示<iframe>内容。
示例代码如下:
<iframe height=498 width=510 style = "display:block;"src='https://www.toutiao.com/i6790673377188119052/'></iframe>
页面效果如下:
是不是很有意思。
下面我们来介绍一个更有趣的玩法。如图所示:
这个怎么做呢?
这就要介绍<iframe>标签中的另一个属性:name(名字)
示例代码如下:name="iframe"
<iframe name = "iframe" height=498 width=510style = "display:block;"src='https://www.toutiao.com/i6790673377188119052/'allowfullscreen'></iframe>
这里讲个题外话,如果大家了解中国古代的"请神术"的话就会知道这样一个有趣的传说,就是如果我们能叫出鬼神的名字就可以驱使它。
编程也是这样,我们给函数或变量一个名字后,就可以随时随地的驱使它。
现在我们给<iframe>起了个名字叫做"iframe",当然您可以使用其他名字也没问题,但要使用英文或汉语拼音命名,名字是英语字母组合最好。
有了名字之后,<a>标签就要驱使<iframe>标签来显示自己路径下的内容,如何驱使呢?
大家还记得<a>标签中有一个target属性吗?只要让target="iframename"即可!
也就是target="iframe"。示例代码如下:大家要注意的是<a>标签也是内联元素,也需要添加display:block,不然也是排在一列显示。
<a style = "display:block;" target="iframe" href="https://www.toutiao.com/i6790673377188119052/">HTML中的块级元素与内联元素——零基础自学网页制作</a><!--第一个a链接的是头条文章-->
<a style = "display:block;" target="iframe" href="https://baike.baidu.com/item/%E6%AD%BC-20/1555348?fromtitle=%E6%AD%BC20&fromid=1838467&fr=aladdin"> 歼20战斗机百科</a><!--第二个a链接的是百度百科-->
<a style = "display:block;"target="iframe" href="image1.jpg">IT美女</a><!--第三个a链接的是本地图片-->
<iframe name = "iframe" height=498 width=510style = "display:block;"></iframe>
只要我们为不同的<a>标签赋予target="iframe"的属性,点击这些<a>标签就可以在叫做"iframe"的框架元素中显示自己的页面。这时我们可以把<iframe>标签中的src属性删除掉,保存文件后,关闭测试网页,再重新打开,效果如下:
初始状态下,因为框架元素中的src是空的,所以打开后是空白的。如果您觉得单调可以任意复制3个<a>中的一个href中的链接路径给<iframe>的src属性,打开就是相应的标签。这个就不演示了,大家自己试试即可。
点击第一个链接效果如下:
点击第二个链接如下:
点击第三个链接如下:
最后再强调一下,改完框架的src属性后需要关闭页面后重新打开才可以,刷新的话并不能正确显示!切记!
今天的示例代码如下:
<!DOCTYPE HTML>
<html>
<head>
<title>在页面中嵌入页面</title>
</head>
<body>
<a style = "display:block;" target="iframe" href="https://www.toutiao.com/i6790673377188119052/">HTML中的块级元素与内联元素——零基础自学网页制作</a>
<a style = "display:block;" target="iframe" href="https://baike.baidu.com/item/%E6%AD%BC-20/1555348?fromtitle=%E6%AD%BC20&fromid=1838467&fr=aladdin">歼20战斗机百科</a>
<a style = "display:block;" target="iframe" href="image1.jpg">IT美女</a>
<iframe name = "iframe" height=498 width=510 style = "display:block;"></iframe>
</body>
</html>
今天的内容结束了,明天我将会为大家介绍<object>和<embed>这两个标签,它们可以在页面中嵌入更多有趣的东西。
喜欢的小伙伴请关注我,阅读中遇到任何问题请给我留言,如有疏漏或错误欢迎大家斧正,不胜感激!
HTML序章(学习目的、对象、基本概念)——零基础自学网页制作
HTML是什么?——零基础自学网页制作
第一个HTML页面如何写?——零基础自学网页制作
HTML页面中head标签有啥用?——零基础自学网页制作
初识meta标签与SEO——零基础自学网页制作
HTML中的元素使用方法1——零基础自学网页制作
HTML中的元素使用方法2——零基础自学网页制作
HTML元素中的属性1——零基础自学网页制作
HTML元素中的属性2(路径详解)——零基础自学网页制作
使用HTML添加表格1(基本元素)——零基础自学网页制作
使用HTML添加表格2(表格头部与脚部)——零基础自学网页制作
使用HTML添加表格3(间距与颜色)——零基础自学网页制作
使用HTML添加表格4(行颜色与表格嵌套)——零基础自学网页制作
16进制颜色表示与RGB色彩模型——零基础自学网页制作
HTML中的块级元素与内联元素——零基础自学网页制作
初识HTML中的<div>块元素——零基础自学网页制作
在HTML页面中嵌入其他页面的方法——零基础自学网页制作
封闭在家学网页制作!为页面嵌入PDF文件——零基础自学网页制作
HTML表单元素初识1——零基础自学网页制作
HTML表单元素初识2——零基础自学网页制作
HTML表单3(下拉列表、多行文字输入)——零基础自学网页制作
HTML表单4(form的action、method属性)——零基础自学网页制作
HTML列表制作讲解——零基础自学网页制作
为HTML页面添加视频、音频的方法——零基础自学网页制作
音视频格式转换神器与html视频元素加字幕——零基础自学网页制作
HTML中使用<a>标签实现文本内链接——零基础自学网页制作
数字时代,多媒体元素如视频、音频、图片和动画成为了网页设计中不可或缺的一部分。它们不仅能够提升用户体验,还能有效地传达信息和情感。在本文中,我们将探讨如何在网页中嵌入各种多媒体元素,并提供一些例子来说明如何使用它们。
图片是最常见的多媒体类型之一。在HTML中,我们使用 <img> 标签来嵌入图片。
<img src="example.jpg" alt="描述性文字" width="500" height="300">
在这个例子中,src 属性指定图片的路径,alt 属性提供图片的替代文本(对于视觉障碍用户和图片无法加载的情况非常有用),width 和 height 属性指定图片的尺寸。
视频可以提供动态的视觉体验和信息。HTML5引入了 <video> 标签,使得嵌入视频变得简单。
<video width="640" height="360" controls>
<source src="movie.mp4" type="video/mp4">
<source src="movie.ogg" type="video/ogg">
您的浏览器不支持视频标签。
</video>
在这个例子中,controls 属性添加了视频播放控件,如播放、暂停和音量控制。<source> 标签允许指定多个视频格式,以确保跨不同浏览器的兼容性。
音频元素可以用来播放声音或音乐。HTML5通过 <audio> 标签提供了对音频内容的支持。
<audio controls>
<source src="sound.mp3" type="audio/mpeg">
<source src="sound.ogg" type="audio/ogg">
您的浏览器不支持音频元素。
</audio>
与视频标签类似,controls 属性为音频文件提供了基本的控制选项,而 <source> 标签让我们可以指定多个音频格式。
除了直接嵌入文件,我们还可以嵌入整个网页或者其他网站的内容,比如地图或社交媒体帖子。这通常是通过 <iframe> 标签完成的。
<iframe src="https://www.example.com" width="600" height="400">
<p>您的浏览器不支持iframe标签。</p>
</iframe>
在这个例子中,src 属性指定了要嵌入的网页的URL,width 和 height 属性设置了iframe的尺寸。
SVG(可缩放矢量图形)和Canvas API是创建网页动画和图形的两种流行技术。
<svg width="100" height="100">
<circle cx="50" cy="50" r="40" stroke="green" stroke-width="4" fill="yellow" />
</svg>
这个SVG示例创建了一个简单的带有绿色边框和黄色填充的圆。
<canvas id="myCanvas" width="200" height="100"></canvas>
<script>
var c = document.getElementById("myCanvas");
var ctx = c.getContext("2d");
ctx.fillStyle = "#FF0000";
ctx.fillRect(0, 0, 150, 75);
</script>
这个Canvas示例使用JavaScript在画布上绘制了一个红色的矩形。
我们还可以嵌入社交媒体平台上的内容,如推文或Instagram帖子。
<!-- Twitter -->
<a class="twitter-timeline" href="https://twitter.com/TwitterDev?ref_src=twsrc%5Etfw">Tweets by TwitterDev</a>
<script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>
<!-- Instagram -->
<blockquote class="instagram-media" data-instgrm-permalink="https://www.instagram.com/p/B1JWcqCgsdH/">
</blockquote>
<script async defer src="//www.instagram.com/embed.js"></script>
这些例子展示了如何嵌入Twitter和Instagram的内容。通常,社交媒体平台提供了易于嵌入内容的代码片段。
嵌入多媒体元素可以极大地提升网站的吸引力和互动性。通过使用HTML的 <img>, <video>, <audio>, <iframe>, <svg> 和 <canvas> 标签,我们可以在网页中添加丰富的视觉和听觉内容。此外,社交媒体的嵌入功能使得分享和展示社交媒体内容变得简单。当设计包含多媒体元素的网页时,记得考虑到所有用户的访问性,确保内容对所有人都是可访问的。
*请认真填写需求信息,我们会在24小时内与您取得联系。