前端性能精进(七)——构建
前端构建是指通过工具自动化地处理那些繁琐、重复而有意义的任务。这些任务包括语言编译、文件压缩、模块打包、图像优化、单元测试等一切需要对源码进行处理的工作。
PC GWP-ASan方案原理 | 堆破坏问题排查实践
字节APM-PC平台开发实现了堆破坏检测利器——GWP-ASan,帮助字节内部业务剪映在PC端快速定位解决了多个疑难堆破坏问题。本文详细介绍了PC GWP-ASan的原理与方案,并提供了多个实践案例。
插件化框架相关性能优化
插件化框架的发展经历了四个阶段:探索阶段、发展阶段、品质阶段、体验阶段。各个阶段有各个阶段需要完成的使命。。需要通过不断的熟读系统的代码和写的老代码,不断的挖掘瓶颈问题,见微知著,保持好奇,勇于尝试。
前端性能精进(六)——网络
网络也是前端性能优化的重要一环,网页上的资源都要经过网络来传输。优化网络性能除了缓存和压缩之外,还有就是协议和 CDN
iOS Monorepo 全源码解决方案
Monorepo 全源码方案为大型移动端开发提供了全面可行性验证以及宝贵经验。未来,我们会将现有的功能回馈到 bazel 社区,并且推出一系列文章来讲述 BitSky 套件的工作流程及原理。
前端性能精进之浏览器(五)——JavaScript
JavaScript 是一种通过解释执行的高级编程语言,同时也是一门动态、弱类型的直译脚本语言,适合面向对象(基于原型)和函数式的编程风格。
前端性能精进之浏览器(四)——呈现
本文第一章节详细描述了资源的优化,并在开篇指出资源都存在着优先级,浏览器会按优先级进行请求。预加载可提升资源的优先级,预提取可降低资源的优先级,预连接可提前进行 TCP 连接或 DNS 查询。
前端性能精进之浏览器(三)——图像
本文对图像的优化进行了系统性的梳理,首先是对请求做优化。为了更科学的对图像进行请求,列出了懒加载、预加载和 Data URI 三种优化方法。
前端性能精进之优化方法论(二)——分析
在上一节中曾提到过两种性能监控:SYN 和 RUM,那么对应的也有两种分析:数据分析和实验室分析。数据分析会通过采集上来的性能信息来剖析和定位可能存在的各种问题。
前端性能精进之优化方法论(一)——测量
本文的示例代码摘取自 shin-monitor,一款开源的前端监控脚本。为了便于记忆,特将此系列的所有重点内容浓缩成一张思维导图
火山引擎推出一站式小程序监控方案
火山引擎 APM 团队打造出一站式小程序监控平台,旨在为开发者提供可跨平台、监控能力完善、简单易用的小程序监控服务。
NAPI-RS 是怎么工作的: 从 NAPI 到 Build Script & FFI
NAPI-RS 是一个在 Rust 下编写高性能 Node.js 扩展的框架,底层使用 N-API 进行交互。本文从 Build Script 与 FFI 出发简单介绍了 NAPI-RS 的实现原理
辞旧岁立新年 | 展望前端工程师的2023
字节前端工程师黄健参与「InfoQ 2022年度技术盘点与展望」,展望前端研发工程师的 2023,从前端工程师与云原生;回顾过去,畅谈未来;职业发展,未来前景三个部分展开精彩分享。
Monorepo 下 Git 工作流的最佳实践
本文从适合小型 Monorepo 的 Feature branch 工作流开始分享,接着分享适用于中大型 Monorepo 的 Trunk-based 工作流,并给出一些选型标准供参考。
React Streaming SSR 原理解析
React 18 提供了一种新的 SSR 渲染模式: Streaming SSR,实现了Streaming HTML和Selective Hydration的特性,本文将从原理和源码两个方面,对Streaming SSR进行解析
从零开始搞监控系统(7)——监控页面奔溃
  页面奔溃包含两种场景,第一种是浏览器在加载网页时遇到问题导致的奔溃,另一种是因为脚本渲染出错导致页面空白无内容的奔溃。  前段时间运营抱怨有张活动页出现了空白(第二种奔溃场景),导致用户无法访问,希望我们能主动监控到这种情况,而不是通过用户的上报。  后面和运维沟通,他那边目前只能监控接口的
从零开始搞监控系统(6)——较长的白屏时间
一、加载慢  在直播间有一个小时榜的Web页面,经常有用户反映点击小时榜,弹出的页面会有蛮长的一段(3秒上下)时间白屏。    查看性能监控中的白屏时间,发现最多1.6秒,最少0.4秒平均每小时的白屏在1秒左右(有待优化),那么大概还有2秒的时间可能是其他原因造成的。    在页面中会包含
React Server Component: 混合式渲染
Server Component 顾名思义是在服务端渲染的组件,它是如何进行渲染的?和 SSR 又有什么区别?让我们来一起探索它究竟是个什么?

有开始,就会有进​步!

在追求性能的道路上,记录每一刻的成长!源码解读,编程技巧,外文翻译,技术实践,线上案例等等,记录自己,启发他人!

专家作者推荐

巡山小汪

关注微信公众号《解Bug之路》,有问题请在公众号中咨询:) 无论多么艰苦的时刻,都不要忘记,辉煌的未来,在你的眼中闪耀!

飞哥开发内功

《深入理解Linux网络》作者,腾讯搜狗十年工程师,公众号「开发内功修炼」作者!

踩刀诗人

聊聊技术,唠唠段子,偶尔做菜写诗,欢迎关注我的公众号 踩刀诗人

Brand

搜索关注微信公众号【架构与思维】:撰稿者为bat、字节的几位高阶研发/架构,专注技术分享。

专题推荐

Netty 是一个异步事件驱动的网络通信层框架,用于快速开发高可用高性能的服务端网络框架与客户端程序,它极大地简化了 TCP 和 UDP 套接字服务器等网络编程。
作者:闪电侠,《跟闪电侠学 Netty》已出版了。书的前半部分是掘金小册中的内容:通过一个完整的 IM 项目入门 Netty;后半部分用了较大的篇幅来介绍 Netty 的底层原理,也会穿插讲一些源码阅读的思路,希望能够帮助到你。
13篇文章21840阅读量
Out of memory (OOM) 是一种操作系统或者程序已经无法再申请到内存的状态。经常是因为所有可用的内存,包括磁盘交换空间都已经被分配了。OOM的官方解释是:Understand the OutOfMemoryError Exception,根据HeapDump性能社区专属讲师公与的总结,常见的OOM有以下10种(其中OOM Killer是操作系统层面的概念)。
11篇文章12748阅读量