身担运营、推广职责的人员，通常会对特定的运营类、推广类页面有较为精准的数据统计需求，因为他们在制定相关报表时，经常会以单个运营活动为中心进行数据组织

则上述人员在使用 ga 时，会希望数据视图只展示某个特定活动的数据，故他们在提相关活动需求时，每个活动都会给出新的 ga 埋点需求。

但其实，ga 本身已经给出了更为优雅的使用方式

今天接手老项目，因为环境问题、配置问题浪费了很多时间，于是花了 30 秒考虑该如何尽量杜绝此类问题：

• 要求老项目交接人提供清晰的配置文档、环境说明文档（比如 node、npm 的版本号）
• 要求老项目交接人提供各项环境都配置完成的 docker
• 建立好持续集成，在持续集成机制中有保留完成的环境配置

差异

• windows

1

set NODE_ENV=production node xxx.js

• mac

1

export NODE_ENV=production node xxx.js

set node_env cross platform

1

$ npm install --save-dev cross-env

在web 性能优化之图片部分中收集了一个把图片转换为低质量 base64code 的工具： lqip-loader。但具体如何将低质量图片占位符和图片逐步加载相结合，就需要自行实践。以下是一次实践探索。

一般而言，在静态资源中，图片大小占比远大于 js、css 大小占比。对图片压缩的一些体积，可能已经比完整的 js、css 文件要大。故在 web 性能优化范畴中，图片优化是非常重要的组成部分。

前两天看到个关键词是“github action”，经查询了解到是 github 的持续集成服务，今天来进行配置尝试

跑 roadhog 开发环境构建时，roadhog 抛出

1
2

? Something is already running on port 8000.
Would you like to run the app on another port instead? (Y/n)

但我检查后发现 8000 端口并未被占用

windows 和 os x 默认不区分文件名大小写

linux 是默认区分文件名大小写

另外观察到，至少在 os x 下，git 默认也不区分文件名大小写

这就很容易带来问题

估计和文件系统有关，先不深究

阅读全文 »

当前 web 应用访问速度过慢，用户等待时间过长，对用户体验造成很大影响。而用户访问 web 页面等待时间过长，会降低用户对品牌的信任度，加大了品牌运营工作的困难度

另外，搜索引擎会降低加载速度过慢站点的权重，使站点曝光率下降

想让源文件加入到构建流程中去被 Webpack 控制，配置 entry。
想自定义输出文件的位置和名称，配置 output。
想自定义寻找依赖模块时的策略，配置 resolve。
想自定义解析和转换文件的策略，配置 module，通常是配置 module.rules 里的 Loader。
其它的大部分需求可能要通过 Plugin 去实现，配置 plugin。