摘要：
要有效地监控和分析您的外部链接,您需要跟踪以下几个关键指标:1.反向链接数量反向链接数量是指指向您网站的外部链接总数。这个指标可以帮助您了解您的网站在网络上的知名度和影响力。更多的... 要有效地监控和分析您的外部链接,您需要跟踪以下几个关键指标:
1. 反向链接数量
反向链接数量是指指向您网站的外部链接总数。这个指标可以帮助您了解您的网站在网络上的知名度和影响力。更多的反向链接通常意味着您的内容和品牌在行业中更受关注。
3. 链接锚文本
链接锚文本是指用户在点击链接时看到的文本。合适的锚文本可以帮助搜索引擎更好地理解您网站的内容,从而提高您的搜索引擎排名。您应该关注与您网站内容相关的锚文本。
4. 链接位置
链接在网页中的位置也很重要。通常情况下,页面顶部和导航栏中的链接会比页面底部的链接产生更多价值。
5. 链接类型
外部链接可以是dofollow(被搜索引擎追踪)或nofollow(不被搜索引擎追踪)。您应该关注dofollow链接,因为它们可以更好地影响您的搜索引擎排名。
一旦您开始跟踪这些指标,下一步就是分析数据以优化您的链接策略。以下是一些建议:
1. 识别最有价值的链接
仔细分析每个外部链接的质量和相关性。哪些链接为您的网站带来最多的流量和曝光度?哪些链接与您的内容最相关?这些将是您应该重点关注的链接。
2. 发现链接漏洞
检查您网站上的"死链接"(链接指向已不存在的页面)。这些链接不仅会影响用户体验,也可能会降低您的搜索引擎排名。您应该及时修复这些链接。
3. 优化链接锚文本
分析您网站上的锚文本,看看哪些是最有效的。您可以根据这些数据调整锚文本,使其更加吸引用户点击和有利于搜索引擎优化。
4. 建立更多高质量的外部链接
利用您从数据分析中获得的见解,主动寻求来自权威、相关网站的外部链接。这将有助于提高您的搜索引擎排名和网站流量。
监控和分析外部链接指标数据对于优化您的链接策略至关重要。通过跟踪关键指标并深入分析数据,您可以更好地了解哪些链接最有价值,从而调整您的链接建设计划。这样做不仅可以提高您的搜索引擎排名,还可以为您的网站带来更多有价值的流量。
seo优化效果评估？
SEO优化效果评估是通过分析网站在搜索引擎中的排名、流量、转化率等方面的变化来确定优化效果的一种方法。以下是一些可能用于评估SEO优化效果的指标：
网站数据分析,主要分析哪些数据?
网站数据分析有很多方面，但是要看你能够获取的是哪些数据，具体如下：1、流量统计是基础的数据统计网站的统计工具可以让我们了解基本流量信息，包括独立访问者、访问停留时间、页面停留时间、访问率等;实时了解网站的变化趋势，了解有效覆盖人群的规模，了解推广的目标人群，在哪个页面，哪个频道。 1.了解网站的目标人群特征，为产品设计提供重要依据2.了解网站关注行业用户量的潜在规模3.与行业平均指标做对比，作为评估自身网站发展的指标4.分析网站与竞争对手之间的用户重合度5.分析自身网站内部各栏目间的用户重合度根据网站的大致需求，相关网站“数据统计”的基本分析应具有：A.访问人次，即网站的访问人次，通常以日访问人次统计，此指标不排除同一访客同一天访问多次。 B.访问总页面数，即访问者在站点上浏览的总页面数，通常以日统计。 C.独立访客，也称独立IP，指访问站点的独立访客，通常以日访问人次统计，每台独立上网电脑被视为一个独立访问者。 同一电脑多人使用时，不重复计算，仍视作一个独立访问者。 D.人均停留时间，即访问者在网站停留的时间计算公式：人均停留时间=访问人次停留时间/访问人次。 指“独立访问者”平均每次访问某一网站的停留时间。 也就是说一个周期内，从开始访问这个网站到结束访问这个网站所停留的时间。 E.人均访问页数(PV值)，即访问者平均访问页面数，计算公式：PV值=访问总页面数/访问人次。 这项指标同样重要，访问者平均访问页数越多，越能实现网站的目的指向。 F.跳出率，即访问者到达站点后浏览页数仅有的一页的比率。 G.新访客，即访问站点的访问者是否第一次登录站点，该指标从一侧面反应平台的人气程度和知名度，通常以日为单位进行统计。 每日新访客人数越多，说明人气越高，影响度也越来越高。 H.回访者，即访问站点的访问者超过一次以上登录站点，该指标从一侧面反应访问者对站点的接受程度，通常以日为单位进行统计，回访人数越多，说明站点被接受的程度越高，而通常，网站的潜在客户行为，就是在回访者中实现，如注册、购物、消费等。 I.每个独立访问者访问频次：一个周期内独立访问者的平均访问次数。 2、关键字数据收集包括两方面：客户通过哪些关键字到达网站客户在网站搜索哪些关键字---精确地跟踪有哪些关键字产生了销售额或销售机会3、网站专题及营销方式的效果统计精确地跟踪有哪些专题产生了销售额或销售机会，跟踪由专题转换为销售的点击次数帮助我们评估网站页面格局的合理性跟踪销售额和销售机会
一文摸清前端监控实践要点（一）性能监控
前言前端监控是一个历史长久的话题了，目前一提到监控平台，大部分开发同学想到的是什么？没错，sentry，那么我们这篇文章为什么要自己搞呢？
很简单，团队项目要钱呐，数据量越大费用越高；并且不方便团队做自己的数据分析以及埋点设计，还有前端后端全链路的一个API请求链路分析也不方便；另一方面，自己搞一个是自己的技术提升，只会用不知怎么回事，那怎么行~
所以这部整理了一下自己在团队中自建浏览器环境下前端监控的实践经验，整理成文分享出来：
一般来说，前端搭建监控体系，可以概括为为了做两件事：如何及时发现问题、如何快速定位问题，而为了解决这两个问题，前端监控体系需要关注的点可以拆分为如下：
页面的性能情况：包括各阶段加载耗时，一些关键性的用户体验指标等
用户的行为情况：包括PV、UV、访问来路，路由跳转等
接口的调用情况：通过http访问的外部接口的成功率、耗时情况等
页面的稳定情况：各种前端异常等
数据上报及优化：如何将监控捕获到的数据优雅的上报
如果全部内容都放在一篇文章中进行说明，会导致过于冗长且失去层级，所以本篇中只介绍前端监控的第一部分：页面性能监控；
页面的性能情况我们都听说过性能的重要性。但当我们谈起性能，以及让网站速度提升时，我们具体指的是什么？
其实性能是相对的：
某个网站可能对一个用户来说速度很快（网速快，设备强大的情况下），但可能对另一个用户来说速度很慢（网速慢，设备低端的情况下）。
两个网站完成加载所需的时间或许相同，但其中一个却显得加载速度更快（如果该网站逐步加载内容，而不是等到最后才一起显示）。
一个网站可能看起来加载速度很快，但随后对用户交互的响应速度却很慢（或根本无响应）。
因此，在谈论性能时，重要的是做到精确，并且根据能够进行定量测量的客观标准来论及性能。 这些标准就是指标。
而前端性能监控，就是要监测页面的性能情况，将各种的性能数据指标量化并收集
W3C标准化官方地址：NavigationTimingLevel2
为了帮助开发者更好地衡量和改进前端页面性能，W3C性能小组引入了NavigationTimingAPI，实现了自动、精准的页面性能打点；开发者可以通过属性获取。
下图是W3C第一版的NavigationTiming的处理模型。
上图Level1的规范，2012年底进入候选建议阶段，至今仍在日常使用中；但是在W3C的议程上，它已经功成身退，让位给了精度更高，功能更强大，层次更分明的Level2（处理模型如下图）。 比如独立划分出来的ResourceTiming，使得我们可以获取具体资源的详细耗时信息。
w3clevel2扩充了performance的定义，并增加了PerformanceObserver的支持。
图中指标的解读可以在中查看
web-vitalsweb-vitals是一个google开源的一个用以衡量性能和用户体验的工具，我将它放在这里介绍，是因为下文的性能关键指标获取中，有的会介绍通过这个开源插件进行获取的方法；
相比于我们自己手动写，它会替我们覆盖很多兼容和特殊的场景；
它支持了这些指标：获取PerformanceTiming
既然已经有了W3C标准化定义的PerformanceTiming，那我们自然就要获取它并予以活用，用来计算获取我们所需要的性能指标
let?t?=?;//?W3C?Level1??(目前兼容性高，仍然可使用，未来可能被废弃)。if?(typeof??===?function)?{??try?{????//?W3C?Level2??PerformanceNavigationTiming????//使用了High-Resolution?Time，时间精度可以达毫秒的小数点好几位。????let?nt2Timing?=?(navigation)[0];????if?(nt2Timing)?{??????t?=?nt2Timing;????}??}?catch?(err)?{????(err);??}}以用户为中心的性能指标什么叫以用户为中心的性能指标呢？其实就是可以直接的体现出用户的使用体验的指标；目前Google定义了FCP、LCP、CLS等体验指标，已经成为了目前业界的标准；对于用户体验来说，指标可以简单归纳为加载速度、视觉稳定、交互延迟等几个方面；
加载速度决定了用户是否可以尽早感受到页面已经加载完成
视觉稳定衡量了页面上的视觉变化对用户造成的负面影响大小
交互延迟决定了用户是否可以尽早感受到页面已经可以操作
而针对于上面三个方面，我们可以采集以下多种指标进行衡量
白屏（FP）、灰屏（FCP） let?fp?=?0;?//白屏时间??首次非网页背景像素渲染const?paint?=?(paint);//?!==?0)?{??//判断浏览器是否支持paint??fp?=?paint[0];}?else?{??fp?=??-?;??//?这里的?t?是上一个标题内容定义的?PerformanceTiming?哦}paint还定义了一个首次内容渲染（fcp)(灰屏时间)，这里简单说一下获取方式:
我们可以自己手动写一个FCP获取：
new?PerformanceObserver((entryList)?=>?{??for?(const?entry?of?(first-contentful-paint))?{????(fcp,?entry);??}})({?type:?paint,?buffered:?true?});也可以使用google的web-vitals：
import?{getFCP}?from?web-vitals;//?当?FCP?可用时立即进行测量和记录。getFCP();FP首次绘制：页面视觉首次发生变化的时间点。 FP不包含默认背景绘制，但包含非默认的背景绘制。
FCP首次内容绘制：首次绘制任何文本、图像、非空白canvas或者SVG的时间点。
FP和FCP的区别：FCP是首次绘制来自DOM的有效内容的时间点；所以FP可能=FCP，也可能先于FCP。大部分情况下得到的值两者相等；
但假如，我给单页面应用的body元素加了一个背景色，那么FP记录的时间就是开始绘制带背景色的body的时间点，而FCP记录的则是body生成之后，首次绘制来自DOM的有效内容的时间点，这个时候FP的时间点就先于FCP
首次有效绘制（FMP）(首屏）有的同学或许会疑问，上面的灰屏时间，在我看来就是首屏的时间呀？为什么还需要单独开一栏说呢？其实不然，我们再回忆一次灰屏的定义：FCP是首次绘制任何文本、图像、非空白canvas或者SVG的时间点。注意，这里的用词是任何；也就意味着，如果按照这种逻辑，客户端渲染了一个字的时间点，就认为了首屏时间的时间点所在，
FMP首次有效绘制，我们可以定义为页面渲染过中元素增量最大的点，因为元素增量最大的时候，页面主要内容也就一般都渲染完成了；
目前W3C还没有关于FMP的标准化计算定义；但是W3C关于首屏统计已经进入了提议阶段，坐等W3C再次标准化。 可以在github上看到最新的进展,详见w3c/paint-timing。
如果想系统化首屏的计算，可以参考阿里ARMS的FMP文章，或者可以使用手动在代码中埋点的方式进行计算；
最大内容绘制（LCP）LCP是页面内首次开始加载的时间点，到可视区域内最大的图像或者文本块完成渲染的相对时间，是一个以用户为中心的性能指标，可以测试用户主观感知到的页面加载速度，因为最大内容绘制完成时，往往可以认为页面将要加载完成
通常来说，为了提供良好的用户体验，我们应该努力将最大内容绘制控（LCP）制在2.5秒或以内。
我们可以自己手动写一个LCP获取：
new?PerformanceObserver((entryList)?=>?{??const?entries?=?();??const?entry?=?entries[?-?1];??(lcp,?entry);})({?type:?largest-contentful-paint,?buffered:?true?});也可以使用google的web-vitals：
import?{?getLCP?}?from?web-vitals;//?当?LCP?可用时立即进行测量和记录。getLCP();首次输入延迟（FID）通常来说，我们可以认为，FID时间在100ms内的能让用户得到良好的使用体验
我们可以手动写一个FID获取：
new?PerformanceObserver((entryList)?=>?{??const?entries?=?();??const?entry?=?entries[?-?1];??const?delay?=??-?;??(FID:,?delay,?entry);})({?type:?first-input,?buffered:?true?});也可以使用google的web-vitals：
import?{?getFID?}?from?web-vitals;//?当?FID?可用时立即进行测量和记录。getFID();累计布局偏移（CLS）CLS是测量整个页面生命周期（页面可见性变成隐藏）内发生的所有意外布局偏移中最大一的布局偏移分数。 ；每当一个已渲染的可见元素的位置从一个可见位置变更到下一个可见位置时，就发生了布局偏移。
CLS会衡量在网页的整个生命周期内发生的所有意外布局偏移的得分总和。
简单点说，就是正在阅读文章时，突然页面上某些内容发生了改变；或者你正要点击一个链接或一个按钮，但在手指落下的瞬间，哟？按钮来了一拨灵性走位，导致你点到了别的东西；可以看下图：
通常来说，我们应该将CLS分数控制在0.1?或以下
我们可以手动写一个FID获取：
let?clsValue?=?0;let?clsEntries?=?[];let?sessionValue?=?0;let?sessionEntries?=?[];new?PerformanceObserver((entryList)?=>?{??for?(const?entry?of?())?{????//?只将不带有最近用户输入标志的布局偏移计算在内。????if?(!)?{??????const?firstSessionEntry?=?sessionEntries[0];??????const?lastSessionEntry?=?sessionEntries[?-?1];??????//?如果条目与上一条目的相隔时间小于?1?秒且??????//?与会话中第一个条目的相隔时间小于?5?秒，那么将条目??????//?包含在当前会话中。否则，开始一个新会话。??????if?(????????sessionValue?&&?????????-??<?1000?&&?????????-??<?5000??????)?{????????sessionValue?+=?;????????(entry);??????}?else?{????????sessionValue?=?;????????sessionEntries?=?[entry];??????}??????//?如果当前会话值大于当前?CLS?值，??????//?那么更新?CLS?及其相关条目。??????if?(sessionValue?>?clsValue)?{????????clsValue?=?sessionValue;????????clsEntries?=?sessionEntries;????????//?将更新值（及其条目）记录在控制台中。????????(CLS:,?clsValue,?clsEntries);??????}????}??}})({?type:?layout-shift,?buffered:?true?});也可以使用google的web-vitals：
import?{getCLS}?from?web-vitals;//?在所有需要汇报?CLS?的情况下//?对其进行测量和记录。getCLS();以技术为中心的性能指标什么叫以技术为中心的性能指标呢？
我们再来看上面这张之前放过的图，这是W3CPerformanceTimelineLevel2的模型图，图中很多的时间点、时间段，对于用户来说或许并不需要知道，但是对于技术人员来说，采集其中有意义的时间段，做成瀑图，可以让我们从精确数据的角度对网站的性能有一个定义，有一个优化的方向；
关键时间点字段描述计算公式备注FP白屏时间responseEnd-fetchStart从请求开始到浏览器开始解析第一批HTML文档字节的时间。TTI首次可交互时间domInteractive-fetchStart浏览器完成所有HTML解析并且完成DOM构建，此时浏览器开始加载资源。DomReadyHTML加载完成时间也就是DOMReady时间。domContentLoadEventEnd-fetchStart单页面客户端渲染下，为生成模板dom树所花费时间；非单页面或单页面服务端渲染下，为生成实际dom树所花费时间Load页面完全加载时间loadEventStart-fetchStartLoad=首次渲染时间+DOM解析耗时+同步JS执行+资源加载耗时。FirstByte首包时间responseStart-domainLookupStart从DNS解析到响应返回给浏览器第一个字节的时间关键时间段字段描述计算公式备注DNSDNS查询耗时domainLookupEnd-domainLookupStart如果使用长连接或本地缓存，则数值为0TCPTCP连接耗时connectEnd-connectStart如果使用长连接或本地缓存，则数值为0SSLSSL安全连接耗时connectEnd-secureConnectionStart只在HTTPS下有效，判断secureConnectionStart的值是否大于0,如果为0，转为减connectEndTTFB请求响应耗时responseStart-requestStartTTFB有多种计算方式，相减的参数可以是requestStart或者startTimeTrans内容传输耗时responseEnd-responseStart无DOMDOM解析耗时domInteractive-responseEnd无Res资源加载耗时loadEventStart-domContentLoadedEventEnd表示页面中的同步加载资源。采集了上述的关键时间段后，我们可以做出一次页面加载的具体性能瀑图，我们可以根据这个图分析性能优化的方向；
其它也有意义的指标静态资源加载我们可以获取每次加载时所访问的静态资源，将收集到的静态资源做成瀑图等分析图形，来找出导致静态资源加载时间过长的问题所在。
let?fp?=?0;?//白屏时间??首次非网页背景像素渲染const?paint?=?(paint);//?!==?0)?{??//判断浏览器是否支持paint??fp?=?paint[0];}?else?{??fp?=??-?;??//?这里的?t?是上一个标题内容定义的?PerformanceTiming?哦}0静态资源加载的缓存命中率很多的一些资源，比如img图片等，在用户加载后这些资源就会被缓存起来，再下一次进入时判断缓存类型、是否过期来决定是否使用缓存；那么我们就可以统计每一次用户进入时的一个缓存命中率；
那么，如何判断用户的资源是否命中了缓存呢？，其实很简单，如果静态资源被缓存了，它具有以下两个特征：
静态资源的duration为0；
静态资源的transferSize不为0；
根据上面这两个特征，我们就可以计算每次加载的缓存命中率：
let?fp?=?0;?//白屏时间??首次非网页背景像素渲染const?paint?=?(paint);//?!==?0)?{??//判断浏览器是否支持paint??fp?=?paint[0];}?else?{??fp?=??-?;??//?这里的?t?是上一个标题内容定义的?PerformanceTiming?哦}1PS：跨域资源(CDN)获取页面资源时间详情时，有跨域的限制。默认情况下，跨域资源以下属性会被设置为0
redirectStart
redirectEnd
domainLookupStart
domainLookupEnd
connectStart
connectEnd
secureConnectionStart
requestStart
responseStart
transferSize
如果想获取资源的具体时间，跨域资源需要设置响应头Timing-Allow-Origin
对于可控跨域资源例如自家CDN，Timing-Allow-Origin的响应头origins至少得设置了主页面的域名，允许获取资源时间
一般对外公共资源设置为Timing-Allow-Origin:*。
分析得出的指标分析得出的指标，意味着不是一次采集就能得到的指标数据，而指的是对于整个应用来说，对采集上来的众多数据进行分析而得出的指标情况；
首次加载跳出率：第一个页面完全加载前用户跳出率；
慢开比：完全加载耗时超过5s的PV占比；
多维度分析：对地域、网络、页面等多个维度下的性能情况；
参考阅读前端监控-首屏统计的前世今生
web-vitals
W3Cpaint-timing
Google文档-指标
Lighthouse计算源码
原文：