构建多页面应用——静态资源的处理

更新日期: 2019-03-02阅读: 2.6k标签: 多页面

图片的引用方式

而因为在web中,图片有两种主要的引入方式,第一种是<img src="...">,第二种是backgorund-image: url(...)。前者在html中使用,后者在css中使用。


web开发中的图片处理

图片常见的类型有jp(e)g,png,gif,包括现在普遍使用的svg以及webp。svg作为矢量图形,有一定的使用场景,而webp作为未来web开发的趋势,有一定的使用场景,比如:爱奇艺中的轮播图(carousel)中就是用webp,但其他的见到的不多。

现在,web开发中使用最多的还是jpg和png,处理他们,在构建工具中使用url-loader和file-loader就好了,其中file-loader负责图片的拷贝和输出,并会给图片名添加一个hash值。

说到这里,很多人会想到字体图标。以前处理web页面中的图标(icon),使用图片来处理,这样会带来一个性能问题就是http请求的增多,这样会造成服务器的负载压力,同时会带来用户体验的问题,因为会出现页面的局部空白和页面重绘的问题,当然一种解决方案使雪碧图(sprite),但是如果图片过大怎么解决,如何对图片进行分解(大变小的问题),图片的拼接比较困难,最要命的是在引用雪碧图时要进行计算,除此之外就是如何对雪碧图的组成图片进行自定义的删减,而使用字体图标这些问题,都会得到一定程度的解决,当然在构建工具中可以使用webpack-spritesmith这个插件来处理组成雪碧图的图片。

当然,有些特殊的情况,需要使用base64,这里使用url-loader即可。

将图片处理为base64有使用场景,将图片转换为雪碧图亦有使用场景,单独的图片处理也有使用场景(这些使用场景的图片大小从左到右依次增大)。

这些场景在一个web项目中都会涉及到。

虽然使用字体图标可以替代雪碧图,因为字体图标有更小的尺寸,更自由的操作手法(如:图标颜色的自定义),但是一个DIY的web项目还是有些图标还是需要雪碧图。

但是,这里有一个问题,如何在一个项目中同时使用base64,雪碧图,字体图标,单独的图片。


在构建中如何使用多种图片处理方式

在构建多页面应用中,如何解决呢?

字体图标

处理字体图标很简单,如:iconfont(阿里巴巴字体图标库),就像引用css那么简单。

base64

base64的处理,使用url-loader

雪碧图

雪碧图的处理,可使用webpack-spritesmith这个插件

单独的图片

使用file-loader,它负责拷贝url-loader的处理结果,并输出。

上面就是我们常见的图片处理,如果要处理svg可以参考svg-url-loader,如果要处理webp可以参考webp-loader


如何对图片进行优化

对图片进行优化,会带来良好的用户体验。

熟悉图片优化的都知道渐进式(progressive),可参考nuwen.net

jp(e)g可以进行连续性处理,这样可保证图片数据请求回来多少,就渲染多少,是自上而下的渲染,也是有模糊到清晰的状态。

png可以进行交叉处理,这样也可保证图片数据请求回来多少,就渲染多少,它是整体的显示,而且是又模糊状态到清晰的状态。

gif图片一般使用小图,如果是大图会记号浏览器性能,还不如使用视频,或者用css动画来代替。我个人整理了一个css 动画集,有需要的可以看一下。

在构建多页面应用中,会使用到image-webpack-loader来做优化处理。

其中,配置项options中的mozjpeg 处理jp(e)g图片,pngquant处理png图片,gifsicle处理gif图片,webp处理webp图片。


多页面应用中的图片处理

首先,看一下多页面应用中的目录结构图:

./src
│  aboutUs.js
│  contactUs.js
│  css.js
│  index.js
│  recruitment.js
│  
├─assets
│  │  favicon.jpg
│  │  
│  ├─css
│  │  │  index.scss
│  │  │  
│  │  ├─commons
│  │  │  ├─container
│  │  │  │      index.scss
│  │  │  │      
│  │  │  ├─footer
│  │  │  │      index.scss
│  │  │  │      
│  │  │  └─header
│  │  │          index.scss
│  │  │          
│  │  ├─productus
│  │  │      index.scss
│  │  │      productus-sprite.scss
│  │  │      
│  │  └─utils
│  │          btn.scss
│  │          form.scss
│  │          inital.scss
│  │          list.scss
│  │          modeal.scss
│  │          normalize.scss
│  │          pagination.scss
│  │          popover.scss
│  │          table.scss
│  │          text.scss
│  │          tooltip.scss
│  │          
│  └─imgs
│      ├─base64
│      │      fe.jpg
│      │      
│      ├─other
│      │      float.jpg
│      │      productus-sprite.png
│      │      
│      └─sprites
│          └─productus
│                  product-us_01.png
│                  product-us_02.png
│                  product-us_03.png
│                  product-us_04.png
│                  product-us_05.png
│                  product-us_06.png
│                  product-us_07.png
│                  product-us_08.png
│                  product-us_09.png
│                  product-us_10.png
│                  product-us_11.png
│                  product-us_12.png
│                  
├─pages
│  │  recruitment.pug
│  │  template.pug
│  │  
│  └─components
│      ├─commons
│      │  ├─container
│      │  │      index.pug
│      │  │      
│      │  ├─footer
│      │  │      index.pug
│      │  │      
│      │  └─header
│      │          index.pug
│      │          
│      └─productus
│              index.pug
│              
└─utils
        load.js

跟以前的实例代码相比,这次的文件目录结构变化较大,这里将要处理的所有文件模块都放在了src目录下。

可能有人会问,为什么要要将目录分的这么细,下面我就说一下为什么这么分。

  • aboutUs.js, contactUs.js, index.js, recruitment.js是四个路由页面,要用到的js代码,css.js处理各个路由页面公用的css代码;
  • 静态资源目录(assets)下,存放web项目常用的静态资源;
  • 静态资源目录下的css目录统一存放整个web项目所用到的css样式。其中commons存放公用的css模块,每个公用模块有创建一个目录存放该公用模块可以使用到的css模块(提醒,不要分的过于细),而其他的如productus存放产品模块代码,根据开发的需要可以创建其他的模块目录,目录结构类似于commons中的header模块,其中utils放置自己总结的工具模块代码,如table,form等。然后,指定style-loader,css-loader等样式相关的loader处理css样式文件,这样可以减少遍历,缩短构建时间。
  • 静态资源目录下的imgs目录,用来存放整个项目中,用到的图片。在这里,分为base64,sprite,ohter等,为什么要这样分?如果分的话file-loader这个webapck的loader会复制并导出imgs目下所有的图片,者在构建中并不是我们需要的,这样会增加构建的时间。如果让url-loader处理base64目录下的图片,file-loader处理ohter目录下的图片,webpack-spritesmith处理sprite目录下的图片,并将生成的图片放到ohter目录下,用file-loader进行二次处理。这样做,webpack处理更精确,可以减少不必要的遍历,极大地减少构建的时间,同样方便对图片的管理,特别是对于需要改变sprite的图片的管理。
  • 在imgs目录下创建base64目录,sprite目录,使用file-loader指定处理ohter目录,是为了避免file-loader将所有的图片都拷贝一份并导出到dist输出目录中,因为与base64相关的文件已经在css样式文件中了,再拷贝一份,已经没有意义,而sprite相关的文件会被webpack-spritesmith插件先处理生成一个文件,所以再拷贝它们也没有意义,还会让构建速度更慢。
  • 在page目录下,放置所有的html代码块(这里使用pug编译器生成相应的html代码块),它的目录分类和css相类似,它们是一一对应的关系。

注意:iamge-webpack-loader,要先对所有的图片进行优化处理,然后再用其他loader处理。loader的执行顺序,如果你是style-loader!css-loader!sass-loader"使用,它是从右到左方向先后执行,如果你是在配置文件中的rules: [...]数组中,它也是从右到左的方向执行,如果你将所有的loader规则有回车符号隔开,那么它就是自下而上的执行。


一类特殊的图片引用

针对<img src="...">的图片使用,ul-loader是不会处理html中的img引用,现在处理这样情况的loader或插件,也并没有一个比较出名的。现在通用的做法就是将图片拷贝一份到生成目录中,copy-webpack-plugin。参考配置代码如下:

new CopyWebpackPlugin([
  {
  from: path.resolve(__dirname, 'assets/imgs/other/'),
  to: path.resolve(__dirname, 'dist/assets/imgs/other/'),
  ignore: ['.*']
  }
]),

但这样,会带来另一个问题就是图片的优化问题,如何使用 image-webpack-loader?本来的目的是对项目中使用到的所有的图片进行优化,而现在只能对base64和sprite目录下的图片进行优化处理。不过,不要慌,可以通过创建一个新的npm脚本命令(本是里使用的是npm run img)来对图片进行压缩处理,新建了一个目录static用来保存优化前的图片,ohter用来保存优化后的图片。

首先,需要安装imagemin, imagemin-mozjpeg, imagemin-optipng, imagemin-gifsicle :

yarn add imagemin imagemin-mozjpeg imagemin-optipng imagemin-gifsicle --dev

然后,在项目的根目录添加一个优化图片的文件optzing-img.js,代码如下:

const path = require('path')
const imagemin = require('imagemin');
const imageminMozjpeg = require('imagemin-mozjpeg');
const imageminOptipng = require('imagemin-optipng');
const imageminGifsicle = require('imagemin-gifsicle');

(async () => {
    await imagemin(
    [
      path.resolve(__dirname, 'src/assets/imgs/static/*.jpg'),
      path.resolve(__dirname, 'src/assets/imgs/static/*.png'),
      path.resolve(__dirname, 'src/assets/imgs/static/*.gif')
    ],
    path.resolve(__dirname, 'src/assets/imgs/other/'),
    {
      use: [
        imageminMozjpeg(),
        imageminOptipng(),
        imageminGifsicle()
      ]
    }
  );

    console.log('图片优化完成!');
})();

最后,在package.json文件中添加如下的npm命令:

...
"scripts": {
    ...
    "img": "node optzing-img.js"
  },
...

在控制输入npm run img,然后按下回车键就可以得到你所需要的。

注:既然重新定义了图片优化的npm脚本命令,那么,是否需要去掉之前在webpack.config.js中的image-webpakc-loader,当然不需要。主要有两个原因,一个是sprite雪碧图它是用几张小图片合成了一张大图片,这张合成的图片还需要优化;另一个是因为本项目对于存放图片的目录进行了细化。


字体

在web开发中,自定义的字体也是比较常见的,在webpack中它的处理和图片类似,都是使用的 url-loader 和 file-loader。参考代码如下:

...
{
  include: path.resolve(__dirname, 'assets/fonts/'),
  test: /\.(woff2?|eot|ttf|otf)(\?.*)?$/,
  use: [{
    loader: 'url-loader',
    options: {
      limit: 10000,
      name:  isDev ? '[name].[ext]' : '[name].[hash].[ext]',
      outputPath: 'assets/fonts/'
    }
  }]
},
...

新创建了一个fonts目录又来存放项目开发过程中使用的字体。


源代码

webpack4.x multi-page

此后,webpack构建多页面应用系列文章的源代码,都在这个github项目中,webpack3.x multi-page不再维护。

来源:https://segmentfault.com/a/1190000017579965


链接: https://fly63.com/article/detial/2166

webpack 构建多页面应用初探

如何使用webpack构建多页面应用,这是一个我一直在想和解决的问题。网上也给出了很多的例子,很多想法。猛一看,觉得有那么点儿意思,但仔细看也就那样。使用webpack这个构建工具,可以使我们少考虑很多的问题。

vue.js多页面开发环境搭建

利用 vue-cli 搭建的项目大都是单页面应用项目,对于简单的项目,单页面就能满足要求。但对于有多个子项目的应用,如果创建多个单页面

vue多页面项目使用全局Loading组件

多页面vue应用中,在请求接口之前统一加上Loading作为未请求到数据之前的过渡展示。由于多页面未使用vuex做状态管理,只在入口统一注册了bus,所以此例子使用eventbus做事件通信。

vue-cli3 实现多页面应用

公司有专门的审批系统,我现在做的后台管理系统需要接入,移动端和PC端都要有一个页面来展示业务信息。后端不给开俩项目(也确实没必要),所以打算用多页面来解决,PC和移动端放到一个项目里,然后打包到各自的文件夹

Webpack5 搭建React多页面应用

react-multi-page-app 是一个基于 webpack5 搭建的 react 多页面应用。为什么搭建多页面应用:多个页面之间业务互不关联,页面之间并没有共享的数据

如何打造一个react技术栈的多页面的框架应用

现在很多脚手架基本上都是单页面入口的应用,比如create-react-app等,整个的入口就是src/index.js。即使是Next.js,可以使用next export,导出成一个个单独的 html 页面。但在编译时,依然是全量编译,作为本身是为同构直出量身定制的服务端框架

内容以共享、参考、研究为目的,不存在任何商业目的。其版权属原作者所有,如有侵权或违规,请与小编联系!情况属实本人将予以删除!