记录－交流－Web开发知识分享
Qwik是一款语法"接近"react的前端ssr框架, 前段时间看了两篇Qwik相关的文章, 对这个框架有了些兴趣, 但是去网上搜了一下, 发现相关的中文文章几乎没有了, 所以决定对其好好研究一番, 并且写一篇关于Qwik的特点、基础用法、设计概念, 再加上Qwik对我的一些启发, 接下来就一起看看这款黑科技是何方神圣吧。
从入门学习前端开发开始, 我们不断学习到各种前端的优化方式来提高前端代码的性能, 其中"服务端渲染(ssr)"这种模式帮我们大幅提高了使用前端框架开发的项目的首屏性能, 那么ssr的工作流程是什么样的? 下面我们一起简单梳理一下。…
本文为翻译
原文标题：How we cut 99% of our JavaScript with Qwik + Partytown
原文作者：Miško Hevery
原文地址：https://www.builder.io/blog/how-we-cut-99-percent-js-with-qwik-and-partytown?utm_source=pocket_mylist
http://Builder.io 兴奋地向大家的宣布，采用 Qwik 之后，我们的主页即使在移动端，其 PageSpeed Insights 跑分也能达到 100/100。
无论你的应用程序有多大，Qwik 都能帮助网页达到这样的性能。我们用 一系列炫酷的技术 得到了这样的分数，这些技术包括：
AngularJS 的创造者Misko Hevery近期宣布了新网络框架Qwik测试版本的推出，声称无论应用程序有多大，Qwik 都能够快速地构建。在多数情况下，Qwik 会先下载 1KB 的 JavaScript，在需要的时候才会懒加载或预处理程序和应用程序代码。
在一次名为《如何从主线程中移除99%的JavaScript》的演讲中，Hevery 介绍了 Qwik 背后的原理。…
本文介绍了 vivo 短视频用户访问体验优化的实践思路，并简单讲解了实践背后的几点原理。
我们平时在看抖音快手视频的时候，如果滑动到某个视频画面一直几 s 不动的时候，大概率就会划走了，所以在短视频项目中，画面卡顿是非常影响用户体验的，启播速度越快，就越能留住用户。
启播速度简单来说就是从调用开始播放到首帧上屏的时间，大致可分为两部分：…
众所周知，workerman是基于php cli的，由于php cli模式下无法使用php自带的header、sesion、cookie等函数，这导致将传统的php项目无法直接在workerman容器下直接运行。
我一度以为让传统业务在workerman中运行，就必须更改框架甚至业务代码以适配workerman，直到joanhey发了一个issue，打破了我的认知。
他们发布了一个名叫AdapterMan的项目，它可以做到不更改传统框架代码的情况下让你的传统php项目放到workerman中正常运行，并且他们公司已经在生产环境用了2年。
注意，是零代码改动直接让laravel、lumen、Slim等框架的项目在workerman上运行。
目前他们已经在laravel、lumen、Slim、Symfony、CakePHP、Yii2、KumbiaPHP 等做了初步压力测试，性能有很大的提升。
以下是压测结果
| Fw | Plaintext | Json | Single query | Multiple query | Updates | Fortunes |
|---|---|---|---|---|---|---|
| Laravel | 14,799 | 14,770 | 9,263 | 3,247 | 1,452 | 8,354 |
| Laravel Roadrunner | 482 | 478 | 474 |
高并发和响应快对应着性能优化的两个核心指标：吞吐和延时
性能问题的本质就是系统资源已经到达瓶颈，但请求的处理还不够快，无法支撑更多的请求。 性能分析实际上就是找出应用或系统的瓶颈，设法去避免或缓解它们。
对于不同的性能问题要选取不同的性能分析工具。 下面是常用的Linux Performance Tools以及对应分析的性能问题类型。
平均负载：单位时间内，系统处于可运行状态和不可中断状态的平均进程数，也就是平均活跃进程数。它和我们传统意义上理解的CPU使用率并没有直接关系。
其中不可中断进程是正处于内核态关键流程中的进程（如常见的等待设备的I/O响应）。不可中断状态实际上是系统对进程和硬件设备的一种保护机制。
实际生产环境中将系统的平均负载监控起来，根据历史数据判断负载的变化趋势。当负载存在明显升高趋势时，及时进行分析和调查。 当然也可以当设置阈值（如当平均负载高于CPU数量的70%时）
现实工作中我们会经常混淆平均负载和CPU使用率的概念，其实两者并不完全对等：
平均负载高时可能是CPU密集型进程导致，也可能是I/O繁忙导致。具体分析时可以结合mpstat/pidstat工具辅助分析负载来源
CPU上下文切换，就是把前一个任务的CPU上下文（CPU寄存器和PC）保存起来，然后加载新任务的上下文到这些寄存器和程序计数器，最后再跳转到程序计数器所指的位置，运行新任务。其中，保存下来的上下文会存储在系统内核中，待任务重新调度执行时再加载，保证原来的任务状态不受影响。
按照任务类型，CPU上下文切换分为：
…CORS 是许多 API 所必需的，但基本配置会产生大量额外请求，从而减慢每个浏览器 API 客户端的速度，并向您的后端发送不必要的流量。
这可能是传统 API 的问题，但在无服务器平台上会成为一个更大的问题，在无服务器平台上，您的账单通常直接与收到的请求数量挂钩，因此这很容易使您的 API 成本翻倍。
所有这些都是不必要的：它正在发生，因为您不知道缓存如何为 CORS 请求工作。让我们解决这个问题。…
也可以在dev.to上阅读（警告它远大于 14kB）
拥有一个较小的网站可以使其加载速度更快——这并不奇怪。
令人惊讶的是，一个14kB页面的加载速度比一个15kB页面快得多——也许更快——而一个页面和一个页面612ms之间的区别是微不足道的。15kB16kB
这是因为TCP 慢启动算法。本文将介绍它是什么，它是如何工作的，以及为什么你应该关心。但首先我们将快速回顾一些基础知识。…
CSS 文件是渲染阻塞资源：它们必须在浏览器渲染页面之前加载和处理。包含不必要的大样式的网页需要更长的渲染时间。
在本指南中，您将了解如何以优化关键渲染路径和改善 First Contentful Paint (FCP) 为目标来延迟加载非关键 CSS。
以下示例包含一个带有三个隐藏文本段落的可折叠项，每个文本段落都使用不同的类来设置样式：…
为了提高页面加载速度，您可以通过仅调整页面的 HTML 代码来延迟 CSS 和 JavaScript 资源。
CSS、字体和 JavaScript 等资源被视为渲染阻塞。这意味着浏览器在实际呈现页面内容之前需要时间来加载它们。
所以这些资源的文件越大，加载它们的时间就越长，用户看到页面内容的时间就越长。
要检查页面加载速度和渲染阻止资源，您可以直接在浏览器 (Chrome) 中使用Lighthouse工具。这是衡量 Web 性能的重要工具之一。
为了防止渲染阻塞资源减慢您的页面速度，您可以实施下面列出的小 HTML 更改来解决此问题。
处理 CSS 负载的正确方法是将样式拆分为关键 CSS 和非关键 CSS。
近期评论