c84f5ed794
### What? Add the same re-retrieval process for subseted font files of Google Font as for CSS files. + make use of [async-retry](https://github.com/vercel/async-retry) ### Why? It was reported in #45080 that Japanese fonts such as Noto Sans JP were frequently `Failed to fetch`. A retry process was added in #51890, but it did not resolve the issue completely ( https://github.com/vercel/next.js/pull/51890#issuecomment-1614558064 ). Here is my reproduction code with 13.5.5-canary.4 (please run locally). https://stackblitz.com/edit/stackblitz-starters-n8zxlq?file=app%2Fpage.tsx <details> <summary>And my local error log is here(folded)</summary> ``` $ npm run -- dev > nextjs@0.1.0 dev > next dev ⚠ Port 3000 is in use, trying 3001 instead. ▲ Next.js 13.5.5-canary.4 - Local: http://localhost:3001 ✓ Ready in 23.9s ○ Compiling /page ... FetchError: request to https://fonts.gstatic.com/s/notosansjp/v52/-F6jfjtqLzI2JPCgQBnw7HFyzSD-AsregP8VFBEj757Y0rw_qMHVdbR2L8Y9QTJ1LwkRmR5GprQAe69m.4.woff2 failed, reason: at ClientRequest.<anonymous> (/mnt/c/Users/berlysia/Downloads/stackblitz-starters-n8zxlq/node_modules/next/dist/compiled/node-fetch/index.js:1:65756) at ClientRequest.emit (node:events:514:28) at TLSSocket.socketErrorListener (node:_http_client:495:9) at TLSSocket.emit (node:events:514:28) at emitErrorNT (node:internal/streams/destroy:151:8) at emitErrorCloseNT (node:internal/streams/destroy:116:3) at process.processTicksAndRejections (node:internal/process/task_queues:82:21) { type: 'system', errno: 'ETIMEDOUT', code: 'ETIMEDOUT' } ⨯ Failed to download `Noto Sans JP` from Google Fonts. Using fallback font instead. Failed to fetch `Noto Sans JP` from Google Fonts.} FetchError: request to https://fonts.gstatic.com/s/notosansjp/v52/-F6jfjtqLzI2JPCgQBnw7HFyzSD-AsregP8VFBEj757Y0rw_qMHVdbR2L8Y9QTJ1LwkRmR5GprQAe69m.28.woff2 failed, reason: at ClientRequest.<anonymous> (/mnt/c/Users/berlysia/Downloads/stackblitz-starters-n8zxlq/node_modules/next/dist/compiled/node-fetch/index.js:1:65756) at ClientRequest.emit (node:events:514:28) at TLSSocket.socketErrorListener (node:_http_client:495:9) at TLSSocket.emit (node:events:514:28) at emitErrorNT (node:internal/streams/destroy:151:8) at emitErrorCloseNT (node:internal/streams/destroy:116:3) at processTicksAndRejections (node:internal/process/task_queues:82:21) at runNextTicks (node:internal/process/task_queues:64:3) at listOnTimeout (node:internal/timers:540:9) at process.processTimers (node:internal/timers:514:7) { type: 'system', errno: 'ETIMEDOUT', code: 'ETIMEDOUT' } ...(15 errors emitted) ``` </details> I've found that the issue is not limited to fetching CSS, fetching subset font files is also failing. By adding retry handling to the fetch of individual subseted font files as well, I (almost) never see `Failed to fetch` anymore. The issue tends to become more apparent when downloading a larger number of subsetted fonts. This suggests that the problem is more likely to occur with larger fonts, such as those designed for CJK languages. ### How? Add the same re-retrieval process for subseted font files of Google Font as for CSS files. Related to #51890 #53239 #45080 #53279 |
||
|---|---|---|
| .. | ||
| create-next-app | ||
| eslint-config-next | ||
| eslint-plugin-next | ||
| font | ||
| next | ||
| next-bundle-analyzer | ||
| next-codemod | ||
| next-env | ||
| next-mdx | ||
| next-plugin-storybook | ||
| next-polyfill-module | ||
| next-polyfill-nomodule | ||
| next-swc | ||
| react-dev-overlay | ||
| react-refresh-utils | ||
| third-parties | ||