在这个数据驱动的时代, 做什么事情没有数据光凭感觉是不可能了, 关于点击日志, 解决方法无外乎这么三种: 1. 在点击 url 串上带上丰富信息, 然后在后续处理的前端 (比如 nginx 或 apache) 上打印请求日志, 把请求日志汇总过滤得到想要的; 2. 做点击跳转, 用户点击后先跳到自己服务器上, 然后由自己的服务器做重定向, 并记录这一次请求; 3. 前端 JavaScript 监控用户鼠标行为, 并及时上报到服务器. 这三种方法也分别有各自的优缺点, 当时分析的是 1. 这个必须要保证点击后还是跳到自己的服务器上, 否则跳出去的点击无法跟踪. 不太可能丢日志, 只是过滤会多道工序. 目测 Facebook 曾经是这样干的; 2. 绝对完整的记录. 不过需要新增服务器响应跳转请求, 并且如果跳转服务挂了会让用户压根到不了 url 指向的地方. 目前所有的广告服务都是这样 (而且点击串加密), Google 的网页搜索很早就是这样, 百度跟 360 干上后也换成了这种. 根据度厂员工在新浪微博上跟别人的讨论, 即使是百度网页搜索那么大的量, 算上灾备最多 50 台跳转服务器可以搞定 (根据公开资料, 百度每天网页搜索量在十亿这个量级, 按搜索引擎页面点击率 30% 算, 每天至少三亿次点击跳转请求); 3. 可记录的东西非常多, 不仅仅是点击, 而且还有一些页面上的其他 js 行为 (如悬浮, js 展开元素等), 但是会丢 15%~20% 的数据. 跟 360 干架前百度的网页搜索用的这种方式, 刚看了下 FB 也是这种了. 其他的优缺点都比较容易明白, 但是 js 模式会丢 15%~20% 的数据这个非常难理解, 之前我只听到 20% 这个比例, 但是没人告诉我为什么, 昨天跟死猫君说日志的时候他也提到他们那边用 js 记的日志也有 15% 的丢失率, 但是他也只是听说这个比例而不明白原理. 今天跟前端同学讨论, 终于搞懂了为什么是这样. 后端的思维是每发生一次事件就打一条日志, 所以极难发生日志丢失的问题. 而前端不能每发生一次事件就向服务器发请求打一次日志, 这样会带来很大的网络开销并拖慢用户的浏览器, 所以前端都是把要纪录的行为在用户端先缓存, 等积累够若干条或过了若干秒后才向服务器汇总上报, 如果在这个上报条件触发前浏览器崩溃掉, 那日志就没了, 或者用户关掉浏览器也会丢掉这部分数据 (据说有一些方式可以响应关闭事件并上报日志, 但具体方式不了解, 另外前端同学反馈 IE6 下丢数据现象更严重). 所以丢数据这事其实是用户流畅度体验和数据完备性的一个平衡, 如果让用户卡一点那丢失比例就低一点. 另外接 js 汇报日志的服务器压力也是一个要考虑的点, 因为如果真用 js 汇报, 那一定就不止点击这点数据了, 鼠标滚轮, 悬停等事件显然是能有都有, 服务器不一定扛的过来.
使用location对象可以通过很多方式来改变浏览器的位置，每次修改location的属性(hash除外)，页面都会以新URL重新加载。
1. 业界案例 目前前端性能监控系统大致为分两类：以GA为代表的代码监控和以webpagetest为代表的工具监控。 代码监控依托于js代码并部署到需监控的页面，手动计算时间差或者使用浏览器的的API进行数据统计。 影响代码监控数据的因素有以下几种： 浏览器渲染机制； 浏览器对API的实现程度，比如performance API； 工具监控不用将统计代码部署到页面中，一般依托于虚拟机。以webpageTest为例，输入需统计的url并且选择运行次url的浏览器版本，webpageTest后台虚拟机对url进
在上一篇《网站数据统计分析之一：日志收集原理及其实现》中，咱们详细的介绍了整个日志采集的原理与流程。但是不是这样在真实的业务环境中就万事大吉了呢？事实往往并非如此。比如针对前端采集日志，业务的同学经常会有疑问：你们的数据怎么和后端日志对不上呢？后端比你们多了 N%！技术的同学也会问：你们怎么不打后端记日志呢？后端比你们效率和准确性更高。带着这些疑问今天咱们就来聊聊前端日志采集中的这些是是非非。 1、前端 VS 后端到底哪个准？该用谁？ 这应该算是统计分析同学最为关注的问题之一了，到底哪个准我们应该从技术和业
在上一篇基于OIDC的SSO的中涉及到了4个Web站点： oidc-server.dev：利用oidc实现的统一认证和授权中心，SSO站点。 oidc-client-hybrid.dev：oidc的一个客户端，采用hybrid模式。 oidc-client-implicit.dev：odic的另一个客户端，采用implicit模式。 oidc-client-js.dev：oidc的又一个客户端，采用implicit模式，纯静态网站，只有js和html，无服务端代码。 其中hybrid和implicit这两个
最近，需要对业务上的一些性能做一些优化，比如降低首屏时间、减少核心按钮可操作时间等的一些操作；在这之前，需要建立的就是数据监控的准线，也就是说一开始的页面首屏数据是怎样的，优化之后的数据是怎样，需要有一个对比效果。此时，performance 这个API就非常合适了。
本文主要介绍了腾讯视频业务在 2018 年至 2019 年间，从 HTTP 到 HTTPS 的过渡和优化实践。通过优化 CDN、负载均衡、Web 服务器、缓存、内容分发网络等方面的技术，提高了腾讯视频业务的性能、安全性和稳定性。同时，文章还介绍了一些关键优化措施，包括 SSL 证书的选择、部署和优化、HTTP/2 的支持和优化、请求合并和模块化接入等。通过这些优化措施，腾讯视频业务在保持服务稳定、提升用户体验的同时，也实现了成本控制和提高效率。
常常会苦恼，平常做的项目很普通，没啥亮点；面试中也经常会被问到：做过哪些亮点项目吗？
本文分为接入前端性能监控、使用前端性能监控、性能优化三部分，可以通过目录跳转到对应的部分浏览。
本文介绍了如何利用Browsersync这个工具提高前端开发效率，通过具体的使用场景和命令行参数进行了详细说明。
本文从黑产攻击方式、木马恶意行为、监控及防御方案等角度对Lnkr木马进行分析，此类木马影响范围较广，攻击手法多样，但目前国内相关的资料却非常稀少，希望本文的实践经验和总结能对从事相关安全检测的同学有所帮助。
Uptime Kuma是一个开源的监控工具，支持自托管服务，简单易用,而且功能强大。
随着业务的快速发展，我们对生产环境下的问题感知能力越来越关注。作为距离用户最近的一层，前端的表现是否可靠、稳定、好用，很大程度上决定着用户对整个产品的体验和感受。因此，对于前端的监控不容忽视。
2020年10月，美团安全运营平台发现流量中存在恶意JavaScript请求，信息安全部收到告警后立即开始应急处理，通过对网络环境、访问日志等进行排查，最终锁定恶意请求由Chrome浏览器安装恶意插件引起，该恶意JavaScript文件会窃取Cookie并强制用户跳转到恶意色情站点、推广链接等，结合美团威胁情报大数据，发现该插件与Lnkr Ad Injector木马特征吻合。
大家好，我是7small7，一位混迹互联网多年的IT民工。今天来给大家分享一个世界互联网大厂都在用的软件(Fun Debug)。
vue init webpack appname：vue 脚手架使用 webpack 模板初始化一个 appname 项目
在 iOS Safari （其他浏览器和 Android 均不会）上会对那些看起来像是电话号码的数字处理为电话链接，比如：
松哥最近正在录制 TienChin 项目视频～采用 Spring Boot+Vue3 技术栈，里边会涉及到各种好玩的技术，小伙伴们来和松哥一起做一个完成率超 90% 的项目，戳戳戳这里-->TienChin 项目配套视频来啦。 ---- 松哥之前写了两篇文章和大家分享了 TienChin 项目中的菜单数据问题，还没看过的小伙伴请戳这里： Vue 里，多级菜单要如何设计才显得专业？ TienChin 项目动态菜单接口分析 这两篇文章主要是和大家说明了后端如何根据当前登录用户，动态生成一个菜单 JSON。 那么
作者：yangchunwen 作者：yangchunwen 首先要解释一下为什么叫浏览器自动化测试，因为本文只关注发布后页面功能的自动化测试，也就是UI层面的自动化。 浏览器测试有别于js代码的单元测
首先要解释一下为什么叫浏览器自动化测试，因为本文只关注发布后页面功能的自动化测试，也就是UI层面的自动化。 浏览器测试有别于js代码的单元测试，后者一般是发布前的代码功能逻辑测试，在这方面已经有很多比
首先要解释一下为什么叫浏览器自动化测试，因为本文只关注发布后页面功能的自动化测试，也就是UI层面的自动化。
HTTP请求中有一个referer的报文头，用来指明当前流量的来源参考页。例如在www.sina.com.cn/sports/上点击一个链接到达cctv.com首页，那么就referrer就是www.sina.com.cn/sports/了。在Javascript中，我们可以通过document.referrer来获取同样的信息。通过这个信息，我们就可以知道访客是从什么渠道来到当前页面的。这对于Web Analytics来说，是非常重要的，这可以告诉我们不同渠道带来的流量的分布情况，还有用户搜索的关键词等，都是通过分析这个referrer信息来获取的。
概述 为什么输入www.cnblogs.com之后敲一个回车，浏览器就会显示我们所看到的内容？这家伙在背后到底偷偷的干了哪些事情？今天我们就来挖掘一下这背后的故事。 HTTP请求过程 为直观明
ARMS是一款阿里云应用性能管理（APM）类监控产品。一共提供三种监控，应用监控，前端监控，自定义监控。
一般来说产品是按以下方式进行迭代的，我认为循环的起点应该是「收集用户反馈」，我们对页面的优化依据和目标一个重要来源就是用户的反馈，因此说网页优化我们先从网页监控开始聊起。
之前看过其他的二维码登陆劫持漏洞，有的地方写的不是很详细，花了不少时间去研究二维码的原理，才弄懂漏洞。为了照顾更多入门新手，以本人的理解重新总结一遍，二维码登陆原理不是这里的主题，不过有必要熟悉一下流程。
最近David Leo在Full Disclosure上爆出了一个ie的 uxss 漏洞，可以绕过ie的同源策略。FreeBuf也有相关的报道（点我查看）。本文简要分析一下这个漏洞的原理。 攻击过程 <iframe src="redirect.php"></iframe> <iframe src="https://www.google.com/images/srpr/logo11w.png"></iframe> <script> top[0].eval('_=top[1];alert();_.loc
之前已经介绍过Servlet的开发，和HttpServletRequest、HttpServletResponse中的大部分常用方法。现在我们可以通过这几个知识点制作一个简单的登录验证，这个登录验证需要连接数据库，因为用户名和密码存储在数据库中。
完整高频题库仓库地址：https://github.com/hzfe/awesome-interview
路由：我们仨都算是负责运输行业的，但是我只是负责运输线路的确定 路由表：为了避免“转送”送错货物到码头，我就负责指定运输的码头 转送： 我负责具体的货物运输，将货物运输到指定的码头。要是没有“路由表”大哥的帮忙，我肯定一天要在十多个码头来来回回的瞎折腾呢。
通常前端建立搭建监控体系，主要是为了解决两个问题：如何及时发现问题、如何快速定位并解决问题。
由于代码的迭代，导致IE已经完全不支持大部分hexo博客了。但是IE在国内还是拥有着一定的份额，而且还不算是例如360等兼容IE内核的浏览器。
英文 | https://javascript.plainenglish.io/how-to-catch-frontend-exceptions-with-sentry-34773b026ced
随着时代的发展，渐渐的许多大中小公司开始把前后端的界限分的越来越明确，前端工程师只负责前端的事情，后端工程师只管后端的事情。正所谓术业有专攻，一个人如果什么都会，那么每一样都很难达到精通。
https://segmentfault.com/a/1190000018785911
Themeablebrowser是一个外部浏览器插件，它fork自inappbrowser，相比于后者，此插件的目的是提供一个可以与你的应用程序的主题相匹配的in-app-browser，以便给你的应用保持一致的外观和感觉。所以，除了一些主题化的配置外，核心部分使用参考inappbrowser文档。
今天在项目中遇到一个问题，测试时发现使用 vue-router 的 this.$router.push 给 URL 添加参数，不能正常跳转。
ECMAScript是JavaScript的核心，但如果要在web中使用JavaScript，那么BOM则是真正的核心，BOM提供了很多对象，用于访问浏览器的功能，这些功能与任何网页内容无关。
Cookie 为 Web 应用程序保存用户相关信息提供了一种有用的方法。例如，当用户访问咱们的站点时，可以利用 Cookie 保存用户首选项或其他信息，这样，当用户下次再访问咱们的站点时，应用程序就可以检索以前保存的信息。
这几天心血来潮，想了解一下前端监控的相关知识，可是在查看了很多资料之后，发现没有详细介绍前端监控的相关文章，都是讲个大概，反倒是现成的前端监控工具有不少。
以前的项目大多数都是java程序猿又当爹又当妈，又搞前端（ajax/jquery/js/html/css等等），又搞后端（java/mysql/Oracle等等）。
简单来说，phantomjs就是一个运行在node上的webkit内核，支持DOM渲染，css选择器，Canvas，SVG等，在浏览器上能做的事情，理论上，phantomjs 都能模拟做到。 phan
简单来说，phantomjs就是一个运行在node上的webkit内核，支持DOM渲染，css选择器，Canvas，SVG等，在浏览器上能做的事情，理论上，phantomjs 都能模拟做到。
日常开发任务中，对于性能优化或多或少会接触到一些内容，可能也参照过 雅虎35条军规[1]进行过相关的性能优化，但是具体的优化结果以及实际的页面速度如何，我们怎么去看呢？以及出现性能问题了，我们如何通过现有工具进行定位&解决？也就是今天我要给大家介绍的内容主题了「Performance」，主题偏向工具介绍，主要从下面4个方面介绍今天的内容。
1、Web路由需要实现的目标 上一篇文章中我们谈到了SPA（Single-page application）的出现，但SPA的应用有个需要解决的问题，就是浏览器只加载记录了一个html，所以当刷新浏览器时js会重新执行，当前页面的内容便会丢失；页面跳转时浏览器不会向服务器发出新的页面请求，浏览器也就无法前进、后退页面。 所以前端web路由需要实现以下目标： （1）能根据页面URL来获取不同的模块，但不发起新的页面请求； （2）能监听URL的变化。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
腾讯会议
实时音视频
