Blog | 前端面试

图片的懒加载和预加载

2024年11月26日 · 阅读需 5 分钟

Gavin Ray

Maintainer of FE-interview

图片的懒加载（Lazy Loading）和预加载（Preloading）是两种优化网页加载性能的技术，分别针对不同的场景。

懒加载 (Lazy Loading)

懒加载是一种按需加载资源的技术，图片只有在用户即将看到它时（如滚动到视口范围内）才加载，而非页面初始渲染时就加载所有图片。

实现方式

HTML 属性 loading="lazy"
从 HTML5 开始，<img> 标签支持原生的 loading 属性：
```
<img src="example.jpg" alt="example" loading="lazy" />
```
- 浏览器会在图片即将进入视口前自动加载。

Intersection Observer
如果需要支持更复杂的场景或兼容性（如旧版浏览器），可以使用 JavaScript 的 Intersection Observer API：

const images = document.querySelectorAll('img[data-src]');
const observer = new IntersectionObserver((entries, obs) => {
    entries.forEach(entry => {
        if (entry.isIntersecting) {
            const img = entry.target;
            img.src = img.dataset.src;
            obs.unobserve(img);
        }
    });
});

images.forEach(img => observer.observe(img));

在 HTML 中：

<img data-src="example.jpg" alt="example" />

优点

减少首屏加载时间：只加载视口内的图片，加快页面初始渲染速度。
节省带宽：未进入视口的图片不会被加载。

缺点

SEO 影响：对 SEO 不友好的懒加载可能导致搜索引擎抓取不到图片。
兼容性：老旧浏览器可能不支持，需要提供回退方案。

预加载 (Preloading)

定义

预加载是在资源实际需要之前提前加载，以确保资源在需要时立即可用，减少延迟。

实现方式

<link> 标签的 rel="preload"
用于告诉浏览器优先加载某些资源：
```
<link rel="preload" href="example.jpg" as="image" />
```
JavaScript 动态加载
使用 JavaScript 创建 Image 对象来预加载图片：
```
const img = new Image();
img.src = 'example.jpg';
```
CSS 的背景图预加载
使用 @font-face 或 background-image 提前加载图片资源：
```
.preload {
    background-image: url('example.jpg');
    visibility: hidden;
}
```

优点

提升用户体验：资源提前加载，减少交互时的等待时间。
适用于关键资源：如页面首屏大图或重要交互图片。

缺点

增加初始加载时间：预加载会增加初始的网络请求，可能导致首屏渲染变慢。
带宽浪费：如果资源未被实际使用，可能浪费用户带宽。

懒加载 vs. 预加载

特性	懒加载	预加载
目的	减少首屏加载压力，节省带宽	减少资源加载延迟
触发时机	用户需要时（滚动到视口）	页面加载时提前加载
适用场景	非首屏图片或次要资源	首屏关键资源或未来会使用的资源
缺点	可能影响 SEO 和兼容性	增加初始网络请求负担

综合应用

在实际开发中，可以将懒加载和预加载结合使用。例如：

对首屏的关键资源（如 Hero 图片）使用预加载。
对非首屏的次要图片使用懒加载，减少加载压力。

提示

预加载：提前加载图片，当用户需要查看时可直接从本地缓存中渲染。
懒加载：懒加载的主要目的是作为服务器前端的优化，减少请求数或延迟请求数。
两种技术的本质：两者的行为是相反的，一个是提前加载，一个是迟缓甚至不加载。
懒加载对服务器前端有一定的缓解压力作用，预加载则会增加服务器前端压力。

什么是单点登录，以及如何进行实现？

2024年2月10日 · 阅读需 10 分钟

Gavin Ray

Maintainer of FE-interview

什么是单点登录？

单点登录全称Single Sign On（以下简称SSO），是指在多系统应用群中登录一个系统，便可在其他所有系统中得到授权而无需再次登录，包括单点登录与单点注销两部分。

比如：淘宝、天猫都属于阿里旗下，当用户登录淘宝后，再打开天猫，系统便自动帮用户登录了天猫，这种现象就属于单点登录。

登录流程

相比于单系统登录，sso需要一个独立的认证中心，只有认证中心能接受用户的用户名密码等安全信息，其他系统不提供登录入口，只接受认证中心的间接授权。间接授权通过令牌实现，sso认证中心验证用户的用户名密码没问题，创建授权令牌，在接下来的跳转过程中，授权令牌作为参数发送给各个子系统，子系统拿到令牌，即得到了授权，可以借此创建局部会话，局部会话登录方式与单系统的登录方式相同。这个过程，也就是单点登录的原理，用下图说明

单点登录

　下面对上图简要描述

用户访问系统1的受保护资源，系统1发现用户未登录，跳转至sso认证中心，并将自己的地址作为参数
sso认证中心发现用户未登录，将用户引导至登录页面
用户输入用户名密码提交登录申请
sso认证中心校验用户信息，创建用户与sso认证中心之间的会话，称为全局会话，同时创建授权令牌
sso认证中心带着令牌跳转会最初的请求地址（系统1）
系统1拿到令牌，去sso认证中心校验令牌是否有效
sso认证中心校验令牌，返回有效，注册系统1
系统1使用该令牌创建与用户的会话，称为局部会话，返回受保护资源
用户访问系统2的受保护资源
系统2发现用户未登录，跳转至sso认证中心，并将自己的地址作为参数
sso认证中心发现用户已登录，跳转回系统2的地址，并附上令牌
系统2拿到令牌，去sso认证中心校验令牌是否有效
sso认证中心校验令牌，返回有效，注册系统2
系统2使用该令牌创建与用户的局部会话，返回受保护资源

用户登录成功之后，会与sso认证中心及各个子系统建立会话，用户与sso认证中心建立的会话称为全局会话，用户与各个子系统建立的会话称为局部会话，局部会话建立之后，用户访问子系统受保护资源将不再通过sso认证中心，全局会话与局部会话有如下约束关系

局部会话存在，全局会话一定存在
全局会话存在，局部会话不一定存在
全局会话销毁，局部会话必须销毁

前端实现方式

同域名下的单点登录

cookie的domin属性设置为当前域的父域，并且父域的cookie会被子域所共享。path属性默认为web应用的上下文路径

利用 Cookie 的这个特点，没错，我们只需要将Cookie的 domain属性设置为父域的域名（主域名），同时将 Cookie 的path属性设置为根路径，将 Session ID（或 Token）保存到父域中。这样所有的子域应用就都可以访问到这个Cookie

不过这要求应用系统的域名需建立在一个共同的主域名之下，如 tieba.baidu.com 和 map.baidu.com，它们都建立在 baidu.com 这个主域名之下，那么它们就可以通过这种方式来实现单点登录

// 在父域中设置 Cookie
document.cookie = "sessionId=abc123; domain=.example.com; path=/";

// 在子域中读取 Cookie
var cookies = document.cookie.split("; ");
var sessionId;
for (var i = 0; i < cookies.length; i++) {
  var cookie = cookies[i].split("=");
  if (cookie[0] === "sessionId") {
    sessionId = cookie[1];
    break;
  }
}

// 使用 Session ID 进行其他操作
console.log("Session ID:", sessionId);

不同域名下的单点登录(一)

如果是不同域的情况下，Cookie是不共享的，这里我们可以部署一个认证中心，用于专门处理登录请求的独立的 Web 服务

用户统一在认证中心进行登录，登录成功后，认证中心记录用户的登录状态，并将 token 写入 Cookie（注意这个 Cookie 是认证中心的，应用系统是访问不到的）

应用系统检查当前请求有没有 Token，如果没有，说明用户在当前系统中尚未登录，那么就将页面跳转至认证中心

由于这个操作会将认证中心的 Cookie 自动带过去，因此，认证中心能够根据 Cookie 知道用户是否已经登录过了

如果认证中心发现用户尚未登录，则返回登录页面，等待用户登录

如果发现用户已经登录过了，就不会让用户再次登录了，而是会跳转回目标 URL ，并在跳转前生成一个 Token，拼接在目标 URL 的后面，回传给目标应用系统

应用系统拿到 Token 之后，还需要向认证中心确认下 Token 的合法性，防止用户伪造。确认无误后，应用系统记录用户的登录状态，并将 Token 写入 Cookie，然后给本次访问放行。（注意这个 Cookie 是当前应用系统的）当用户再次访问当前应用系统时，就会自动带上这个 Token，应用系统验证 Token 发现用户已登录，于是就不会有认证中心什么事了

此种实现方式相对复杂，支持跨域，扩展性好，是单点登录的标准做法

不同域名下的单点登录(二)

可以选择将 Session ID （或 Token ）保存到浏览器的 LocalStorage 中，让前端在每次向后端发送请求时，主动将LocalStorage的数据传递给服务端

这些都是由前端来控制的，后端需要做的仅仅是在用户登录成功后，将 Session ID （或 Token ）放在响应体中传递给前端

单点登录完全可以在前端实现。前端拿到 Session ID （或 Token ）后，除了将它写入自己的 LocalStorage 中之外，还可以通过特殊手段将它写入多个其他域下的 LocalStorage 中

// 获取 token
var token = result.data.token;
 
// 动态创建一个不可见的iframe，在iframe中加载一个跨域HTML
var iframe = document.createElement("iframe");
iframe.src = "http://app1.com/localstorage.html";
document.body.append(iframe);
// 使用postMessage()方法将token传递给iframe
setTimeout(function () {
    iframe.contentWindow.postMessage(token, "http://app1.com");
}, 4000);
setTimeout(function () {
    iframe.remove();
}, 6000);
 
// 在这个iframe所加载的HTML中绑定一个事件监听器，当事件被触发时，把接收到的token数据写入localStorage
window.addEventListener('message', function (event) {
    localStorage.setItem('token', event.data)
}, false);

前端通过 iframe+postMessage() 方式，将同一份 Token 写入到了多个域下的 LocalStorage 中，前端每次在向后端发送请求之前，都会主动从 LocalStorage 中读取Token并在请求中携带，这样就实现了同一份 Token 被多个域所共享

此种实现方式完全由前端控制，几乎不需要后端参与，同样支持跨域

参考链接：

https://www.cnblogs.com/zbliao/p/13809846.html

懒加载 (Lazy Loading)​

实现方式​

优点​

缺点​

预加载 (Preloading)​

定义​

实现方式​

优点​

缺点​

懒加载 vs. 预加载​

综合应用​

什么是单点登录？​

登录流程​

前端实现方式​

同域名下的单点登录​

不同域名下的单点登录(一)​

不同域名下的单点登录(二)​

懒加载 (Lazy Loading)

实现方式

优点

缺点

预加载 (Preloading)

定义

实现方式

优点

缺点

懒加载 vs. 预加载

综合应用

什么是单点登录？

登录流程

前端实现方式

同域名下的单点登录

不同域名下的单点登录(一)

不同域名下的单点登录(二)