行動裝置友善化

什麼是響應式設計？

響應式設計（Responsive Design）就是讓網站在手機、平板、桌機等不同尺寸的螢幕上都能自動調整版面，保持閱讀體驗順暢。想像你開啟一個網頁，在 12 吋電腦顯示器上看起來很完整；再把畫面縮小到手機時，內容也不會被擠壓或捲動太多，只需要輕觸滑動就能看到所有資訊。

為什麼要用響應式設計？

• 使用者數量：現在大多數人都是靠手機上網，若網站只適合桌機，就會失去大量流量。
• 搜尋引擎優化：Google 以「行動友善」作為排名因素之一；響應式設計能一次符合所有裝置的需求，省下多版面管理麻煩。
• 維護成本低：只要維護一套 HTML/CSS，就能同時支援所有尺寸，避免重複建置。

響應式設計是怎麼工作的？

• 流式格柵（Fluid Grid）：使用百分比 (%) 來設定寬度，而非固定像素(px)。這樣在螢幕變大或縮小時，元素會跟著比例調整。
• 媒體查詢（Media Query）：透過 CSS 指定不同斷點(breakpoint)，當裝置達到該寬度就套用相對應的排版。典型斷點範例：

/* 600px 以下為手機版 */
@media (max-width: 600px) {
  .col-6 { width: 100%; }
}

/* 601-900px 為平板版 */
@media (min-width: 601px) and (max-width: 900px) {
  .col-6 { width: 50%; }
}

• 彈性圖片與影片：使用 max-width: 100%，讓媒體內容隨容器縮放，而不會溢出。

實際範例：一個簡易的響應式格柵

<!-- HTML -->
<div class="row">
<div class="col-6">區塊 A</div>
<div class="col-6">區塊 B</div>
<div class="col-12">區塊 C（全寬）</div>
</div>

.row { display: flex; flex-wrap: wrap; }
.col-6 { width: 50%; padding: 10px; box-sizing: border-box; }
.col-12 { width: 100%; padding: 10px; }

@media (max-width: 600px) {
  .col-6, .col-12 { width: 100%; }
}

如何開始實作？

• 先規劃格柵：決定要使用的列數（常見 12 列）與每個區塊在不同裝置上的寬度。
• 寫好基本樣式：把所有元素都設定為百分比，確保可以流動調整。
• 加入媒體查詢：根據實際需求挑選斷點，並在適合的地方改變排版或隱藏不必要內容。
• 測試多裝置：使用瀏覽器開發者工具切換不同寬度，確認文字、按鈕、圖片都能正常顯示。

常見誤區與解決方案

• 把所有元素固定為 100% 寬度：這樣會讓手機版看起來太擁擠。建議只在必要時使用，全寬排版要留給重要內容。
• 忽略圖片尺寸：不加 max-width 的圖片會超出容器，造成水平捲動；務必在 CSS 加上。
• 過度使用斷點：太多斷點會讓維護成本高。一般來說 2~3 個主要斷點已足夠，除非有特殊需求才再擴充。

小結

響應式設計並不是一個複雜的概念，而是透過簡單的 CSS 原則（流式格柵、媒體查詢、彈性媒體）讓網站能自動適配各種螢幕。只要先規劃好排版邏輯，接著寫出百分比寬度與斷點樣式，就能快速打造一個在手機、平板和桌機上都順手的網站。

媒體查詢技巧：掌握各種裝置尺寸

媒體查詢（@media）是讓 CSS 隨著瀏覽器寬度變化而自動切換樣式的關鍵工具。透過正確設定斷點，網站可以在手機、平板、筆電與桌機上都保持最佳閱讀體驗。

以下是一個常見裝置尺寸對照表，可作為撰寫 @media 的參考：

裝置類型	常見寬度範圍 (px)	建議斷點 (px)
手機（縱向）	320 ~ 480	480
平板（縱向）	481 ~ 768	768
平板（橫向）	769 ~ 1024	1024
輕薄筆電	1025 ~ 1280	1280
標準桌機	1281+	1440

範例：從手機到桌機的樣式變化

/* 手機優先 */
body { font-size: 1rem; line-height: 1.5; }

@media (min-width: 480px) and (max-width: 767px) { /* 平板縱向 */
body { font-size: 1.125rem; }
}

@media (min-width: 768px) and (max-width: 1023px) { /* 平板橫向 */
body { font-size: 1.25rem; }
}

@media (min-width: 1024px) { /* 輕薄筆電以上 */
body { font-size: 1.375rem; }
}

建議實作技巧

• 先寫手機樣式：以最小寬度為基礎，確保在所有裝置上都有可讀的排版。
• 使用相對單位：如 rem、em 或 %，能讓文字與間距隨螢幕比例自動調整。
• 避免過度依賴 max-width：若只設定最大寬度，桌機上可能會出現太寬的內容區塊。
• 測試真實裝置：開發者工具雖方便，但最好在手機、平板、筆電上做一次實際測試，確認切換是否順暢。

進一步閱讀

• MDN Web Docs: Media Queries
• W3Schools: CSS Media Queries Tutorial

Flexbox 與 Grid 是兩種強大的 CSS 排版工具，能讓網站在行動裝置上保持順暢。
本文將分享最佳實踐，包括如何選擇、組合、避免常見坑洞，以及提升載入速度的技巧。

Flexbox 與 Grid 的最佳實踐

Flexbox 與 CSS Grid 雖同屬網路排版，但各自擅長不同任務。以下整理出使用時的重點與技巧，協助你在行動裝置上打造順暢體驗。

1️⃣ 選擇「一維」或「二維」

• Flexbox：適合單一方向（橫向或縱向）的排版，如導航列、卡片列表。
• Grid：專為兩個方向同時控制，適合複雜佈局，例如整體頁面骨架或大型畫廊。

2️⃣ 基本屬性快速上手

• Flexbox:

.container {
  display: flex;
  flex-wrap: wrap; /* 必備，避免內容溢出 */
}
.item {
  flex-basis: 200px; /* 可變寬度基礎值 */
  flex-grow: 1;
}

• Grid:

.container {
  display: grid;
  grid-template-columns: repeat(auto-fill, minmax(250px, 1fr));
  gap: 16px; /* 空隙統一 */
}

3️⃣ 組合使用，互補優勢

• 將 Grid 作為主骨架，再以 Flexbox 調整子項目對齊與間距。
• 例如：在 Grid 的單元格內放置 Flexbox 來排列標題、按鈕與圖示，能保證每個欄位都保持一致排版。

4️⃣ 常見錯誤避免

• 忘記 flex-wrap：Flexbox 預設不換行，導致手機螢幕過窄時內容被壓縮。加上 wrap 可自動換列。
• Grid 列寬過大：使用 minmax() 或 auto-fit/auto-fill 來讓格子隨容器調整尺寸，避免在小螢幕顯示不完整。
• 層疊優先順序錯亂：Flexbox 與 Grid 同時設定 order / grid-area 時，要確認屬性權重，否則會產生預期外的排列。

5️⃣ 性能最佳化小秘訣

• 儘量減少 display: flex; 或 display: grid; 的嵌套層級；太多層級會增加渲染成本。
• 用 CSS 變數或類別統一管理常用尺寸、間距，避免重複計算。

在行動裝置日益普及的今天，網頁圖片若不經最佳化，會造成載入緩慢、資料消耗大等問題。透過使用 HTML5 的 srcset 與 sizes 屬性，可讓瀏覽器自動挑選合適解析度與尺寸的圖檔，提升使用者體驗與 SEO 表現。
以下將以實際範例說明如何在網站中加入這兩個屬性，以及它們對於響應式設計與行動裝置友善化的重要性。

使用 srcset 與 sizes 進行圖片最佳化

為了讓網站在各種螢幕尺寸上都能快速載入且不失真，我們通常會準備多個解析度的相同圖片，並透過 srcset 指定每張圖檔對應的寬度。

1. 準備多尺寸圖檔

• 圖片 A：400px 寬 → image-a-400.jpg
• 圖片 B：800px 寬 → image-a-800.jpg
• 圖片 C：1200px 寬 → image-a-1200.jpg

2. 撰寫 <img> 標籤

<img src='image-a-400.jpg' srcset='image-a-400.jpg 400w, image-a-800.jpg 800w, image-a-1200.jpg 1200w' sizes='(max-width: 600px) 100vw, (min-width: 601px) and (max-width: 1024px) 50vw, 33vw' alt='示例圖片'>
這裡的 srcset 指定了三個不同寬度的圖檔，瀏覽器會根據裝置解析度與佈局寬度挑選最適合的一張。sizes 則告訴瀏覽器「在螢幕最大 600px 時，這張圖片要占滿整個視口；若螢幕介於 601~1024px 時，則占半個視口；其他情況下只佔三分之一」

3. 測試與最佳化

• 使用 Chrome 的 DevTools → Network → Disable cache，觀察不同裝置寬度時載入的檔案大小。
• 確保所有圖檔已經壓縮到合理尺寸（例如使用 WebP 或 AVIF 格式）。

4. 常見問題與建議

• 如果圖片比例不固定，可在 CSS 裡設置 object-fit: cover;，確保不同尺寸的圖都能完整填滿容器。
• 在極小螢幕（如 iPhone SE）上，若仍然載入過大檔案，可以再加一個 200w 的版本並在 srcset 前置：srcset='image-200.jpg 200w, image-400.jpg 400w...'。
• sizes 屬性支援媒體查詢語法，可根據實際佈局調整，例如針對手機、平板與桌面分別設定不同的寬度比例。

結論

srcset 與 sizes 讓瀏覽器能在不額外請求多個圖檔的情況下，依裝置與佈局自動選擇最佳解析度。這不僅提升頁面載入速度，也符合行動優先 SEO 的原則，對於搜尋引擎友善的響應式設計來說，是不可或缺的一環。

避免常見的響應式錯誤：讓手機版也順暢看

你可能覺得只要把 CSS 的 width 設成 100%，網站就能在手機上自動縮排，事實上卻常遇到幾個大坑。以下列出最頻繁的錯誤，以及怎麼用簡單技巧避免。

1️⃣ 盒模型不一致：content-box vs border-box

如果你習慣使用 padding+border 裝飾元素，直接把 width 設成 100% 會讓內容超出螢幕寬度。原因是 CSS 盒子預設為 content-box，padding 與 border 都會加進去。解決方法：

* { box-sizing: border-box; }

這樣 width 就只算內容本身，外層 padding、border 不再佔用額外寬度。

2️⃣ 固定像素的排版：rem/px 混用

在手機上，如果你把某個區塊設成 width: 960px; 或者 max-width: 600px;，那麼小螢幕就會被切斷。改法是用百分比或 vw 單位，或者設定最大寬度但使用百分之百：

.container {
  max-width: 100%;
  width: 100%;
}

再加上 max-width: 1200px; 可以兼顧桌面。

3️⃣ 字體大小不適應：rem 與 media query

如果你只用 font-size: 1rem;，在手機瀏覽器預設的基準字號可能是 16px，但有些手機會縮放。最安全的是設定根元素 html { font-size: 62.5%; } 再以 rem 為單位，或者使用媒體查詢調整：

@media (max-width: 480px) {
  body { font-size: 0.9rem; }
}

這樣就能確保文字不會太大或太小。

4️⃣ 圖片尺寸未自適應：img 的 max‑width

圖片如果沒有設定 max-width: 100%; height: auto;，在手機上就可能跑出畫面外。記得加上這兩行即可解決：

img {
  max-width: 100%;
  height: auto;
}

不管是原圖多大，都會依照容器寬度自動縮放。

5️⃣ 切斷的滾動區塊：overflow‑hidden

有時候你為了美觀把父元素設成 overflow: hidden;，結果在手機上滑不過去。最常見的是水平捲動被鎖住。解決辦法是只針對垂直方向使用 overflow-y: auto; 或者把 hidden 改成 scroll：

.scroll-box {
  overflow-x: hidden;
  overflow-y: auto;
}

這樣就能保留垂直滾動的同時不影響水平布局。

6️⃣ 未加 viewport meta 標籤：

即使 CSS 都寫對，若頁面缺少 <meta name="viewport" content="width=device-width, initial-scale=1">，瀏覽器會把畫面拉寬再縮小，導致排版亂掉。這是最基本的必備項目。

7️⃣ 不合適的媒體查詢條件：

有些開發者習慣用 @media (min-width: 768px) 判斷「桌面」與「手機」，但實際上平板也會被歸在手機範疇。建議把範圍分成三段：手機 <600px、平板 600~1024px、桌面 >1024px。

小結

響應式設計不是寫完 CSS 就算完成，還要不斷測試不同裝置。最簡單的做法是：
1️⃣ 在開發時就使用 box-sizing: border-box;。
2️⃣ 盡量用百分比、vw 或 rem 單位。
3️⃣ 圖片加上自適應屬性。
4️⃣ 加上 viewport meta，並用合理的媒體查詢。
5️⃣ 在手機與平板實機測試，確認沒有被切斷或滾動失效。

只要把這些小細節做好，你的網站就能在任何裝置上順暢顯示，也會對搜尋引擎友善。

行動端速度測試指標說明

在行動裝置上，網頁載入的速度直接決定使用者是否願意停留。這篇教學會帶你了解常用的幾個速度指標，以及它們對體驗和搜尋結果的關係。

主要速度指標一覽表

指標	全名	代表意義	建議目標	範例說明
FCP	First Contentful Paint	第一個畫面元素開始呈現的時間	≤ 1.8 秒	假設你在瀏覽咖啡店網站，首頁第一張招牌照片出現在 1.5 秒內就能讓人感覺流暢。
LCP	Largest Contentful Paint	最大內容區塊完成呈現的時間	≤ 2.5 秒	如產品列表頁面最主要的商品圖片在 2 秒內顯示，使用者不會因等待而跳離。
CLS	Cumulative Layout Shift	頁面整體排版變動程度	< 0.1	若按鈕或文字突然移位造成點擊錯誤，CLS 會上升；保持在 0.05 左右能確保穩定感。
TTFB	Time to First Byte	從發送請求到收到第一個字節的時間	≤ 200 毫秒	例如伺服器回應速度快，網頁開啟時不會有明顯示卡頓。
TTI	Time to Interactive	頁面完全可操作的時間	≤ 3 秒	當使用者可以順利點擊連結或輸入表單時，即算完成 TTI。

如何在 Chrome DevTools 看指標

1. 開啟你想測試的網頁，右鍵選「檢查」或按 F12。

2. 點選上方的 Performance 面板，點擊左上角的錄製圖示（紅圓），再按 Reload 讓瀏覽器重新載入並記錄整個過程。

3. 錄製完成後，畫面會顯示時間軸與各項指標。

4. 在右側的「Summary」區塊，你可以直接看到 FCP、LCP、CLS 等數值；點選 Timings 也能更細節地查看每個階段。

5. 若想比較多個版本，請使用 Save 將錄製結果存檔，再以「Load」載入另一個檔案進行對照。

實務調整小技巧（避免被視為『優化』）

• 壓縮圖片：把 JPEG 或 PNG 改成 WebP，尺寸可減少 40%~50%。舉例來說，一張 800x600 的 PNG 若轉成 WebP，檔案大小可能從 200KB 降至 120KB。

• 延遲載入非首屏內容：將下方的影片或大圖設為 loading="lazy"，讓瀏覽器先把前景畫面加速呈現。這樣即使網路較慢，也能在 1 秒內看到第一張照片。

• 減少 HTTP 請求：合併 CSS 或 JS 檔案，或使用 @import 的方式一次載入多個樣式表。若原本有 10 個獨立檔案，可嘗試縮減到 5 個。

• 利用瀏覽器快取：設定 Cache-Control: max-age=31536000，讓靜態資源在一年內不再重新下載。這對常回訪的使用者來說能顯著降低載入時間。

• 優先呈現關鍵內容：將重要文字或按鈕放在 HTML 原始碼前面、不要被 CSS 隱藏；瀏覽器只要讀到就會馬上渲染，使用者感覺更順暢。

Critical Render Path 簡介

在網頁載入的過程中，瀏覽器要先解析 HTML、取得 CSS 與 JavaScript，再進行佈局與畫面繪製。這整個流程稱為「Critical Render Path」。若此路徑上有重點阻塞，首屏就會被拖延，影響使用者體驗，也可能讓搜尋引擎評估頁面速度時下降。

為什麼重要

1. 使用者離開率：手機網路不佳，若首屏顯示超過3秒，就有大量訪客直接關閉。 2. SEO 排名：Google 已將 Core Web Vitals 包含在排名演算法中，而 FCP（First Contentful Paint）正是其中一項指標。

首屏渲染時間對 SEO 的影響

搜尋引擎會抓取頁面時，若首屏長時間空白，可能認為頁面品質不佳。舉例來說，一篇部落格如果 FCP 為4 秒，與同類型文章 1.5 秒相比，在搜索結果中的點擊率往往低 20%。

實作技巧：縮短首屏渲染

• 將 CSS 標記為 critical：把最先需要顯示的樣式直接寫進 <style>，其餘放在外部檔案。可使用工具（如 Critical、penthouse）自動抽取。
• 延遲載入非關鍵 JavaScript：將 src 標籤加上 defer 或 async，或把腳本移到頁面底部。
• preconnect 與 preload：對於第三方 API（如 Google Fonts、CDN）使用 <link rel='preconnect' href='https://fonts.googleapis.com'> 以提前完成 DNS & TLS。若確定首屏會用到的圖片，則可加上 preload。
• 調整字體載入：選擇 WOFF2、設定 font-display: swap;，或將常用字體行內載入。

範例程式碼

<!DOCTYPE html>
<html lang='zh-Hant-TW'>
<head>
  <meta charset='utf-8'>
  <title>範例頁面</title>
  <!-- preconnect -->
  <link rel='preconnect' href='https://fonts.googleapis.com'>
  <link rel='preconnect' href='https://fonts.gstatic.com' crossorigin>
  <!-- preload 必要字體 -->
  <link rel='preload' href='/fonts/Inter.woff2' as='font' type='font/woff2' crossorigin>

  <!-- 內嵌 critical CSS -->
  <style>
    body{margin:0;font-family:'Inter',sans-serif;}
    .hero{background:#f5f5f5;padding:20px;text-align:center;}
  </style>
  <!-- 延遲載入主樣式表 -->
  <link rel='stylesheet' href='/css/main.css' media='print'>
</head>
<body>
  <div class='hero'>歡迎來到範例頁面！</div>
  <script defer src='/js/app.js'></script>
</body>
</html>

成效表格

技術	主要作用	節省時間 (平均)
Critical CSS	減少渲染阻塞	0.4 秒
defer / async	JavaScript 不影響渲染	0.2 秒
preconnect	DNS/TLS 預取	0.1 秒
font-display: swap	字體不拖累渲染	0.05 秒

• 測試工具：使用 Lighthouse、WebPageTest 或 Chrome DevTools 的 Network 面板，觀察 FCP 與 LCP。持續迭代直到首屏在手機上低於1.8秒。

結語

只要把「先顯示」的資源放進前面、把非必要的腳本與樣式延後，就能大幅降低首屏等待時間。這不僅提升使用者滿意度，也讓搜尋引擎更願意給你好的排名。

Lazy Load 與預取資源策略

在行動裝置上，載入速度直接影響使用者體驗與搜尋排名。當頁面有大量圖片、影片或其他外部檔案時，一開始就把所有資源一次性請求，容易造成畫面卡頓或流量浪費。Lazy Load（延遲載入）和預取策略則是兩個常見且有效的解決方案。

為什麼要使用 Lazy Load

• 節省流量：用戶只會看見他們目前滾動範圍內的內容，其他圖片直到需要時才下載。對於行動網路而言，這能大幅減少資料傳輸。
• 加速首屏渲染：把大量非必要資源從首屏請求中移除，使瀏覽器先完成文字與主要佈局的顯示。

實際範例

假設你有一個長篇文章，內含 20 張圖片。若不使用 Lazy Load，瀏覽器在載入頁面時會同時請求這 20 個檔案；而若啟用後，只會先下載前 3-4 張，其他則等到滑動至對應區塊才下載。

實作方式

1. 原生 lazy attribute（Chrome、Edge、Safari 支援）

<img src="photo1.jpg" loading="lazy" alt="示例圖片">

2. Intersection Observer 方案（較老瀏覽器需要 polyfill）

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

3. 第三方庫（如 lazysizes）

<script src="https://cdn.jsdelivr.net/npm/lazysizes@5.3.2/lazysizes.min.js" async></script>
<img class="lazyload" data-src="photo2.jpg" alt="示例圖片">

預取資源（Prefetch）策略

• 什麼是預取：告訴瀏覽器「這個檔案可能在未來需要，先下載到快取裡」；它不會立即執行，而是在空閒時下載。
• 何時使用：
  • 下一頁的連結（如文章列表中下一篇）
  • 頁面切換頻繁但內容相似的單頁應用程式（SPA）
  • 必要但非首屏立即需要的 CSS/JS 檔案

實作範例

<link rel="prefetch" href="https://example.com/next-article.html" as="document">
<link rel="prefetch" href="https://example.com/styles.css" as="style">

• preload vs prefetch：preload 用於「立即需要」的資源（例如首屏背景圖片），而 prefetch 則用於「將來可能需要」的檔案。

結合 Lazy Load 與 Prefetch

• 先載入主內容：使用 <link rel="preload"> 讓瀏覽器優先下載重要 CSS/JS，確保文字排版正確。
• 延遲非必要圖片：上面示範的 Lazy Load 方法即可。
• 預取下一步資源：在文章末尾放置 prefetch 標籤，讓使用者點擊「閱讀下一篇」前就已經把那篇內容下載好。

測試與工具

• Chrome DevTools 的 Network 面板可以觀察資源的載入順序、大小與延遲時間。
• Lighthouse（內建於 Chrome）提供「行動裝置」速度測試，並會顯示是否有可優化的 Lazy Load 或 Prefetch 建議。
• Google Analytics 的「使用者體驗」報表可以看到實際上線後的載入時間與跳出率變化。

小結

Lazy Load 與預取資源策略是提升行動裝置速度、改善使用者感受、進而影響搜尋排名的重要工具。只要在合適的位置搭配使用，就能讓網站既省流量又不失順暢度，帶給讀者更愉快的瀏覽體驗。

在行動裝置上，網頁載入速度直接影響使用者體驗與搜尋排名。JavaScript 檔案若不經過精簡與合併，會造成大量請求、重複下載以及執行時間延遲。

以下整理了幾個常用的最小化（minify）跟合併（concatenate）技巧，方便你在專案中快速落實。

JavaScript 最小化技巧

• 去除多餘空白與註解：空格、換行以及單行/區塊註解都會佔用檔案大小，經過工具可自動清除。
• 縮短變數名稱：將長字串改為單個字母或兩個字母，能減少 10%~20% 的碼量。記得只在不影響可讀性的範圍內使用。
• 利用現成工具：
  • UglifyJS、Terser：支援 ES6+，提供壓縮與混淆功能。
  • Google Closure Compiler：雖然設定較複雜，但能得到更精簡的輸出。

合併 JavaScript 檔案

• 一次請求多個腳本：把分散在不同頁面或模組的 JS 先合併成一個大檔，減少 HTTP 請求次數。這對於行動裝置的慢速連線尤為重要。

• 使用工具自動化：

  • Webpack 或 Rollup：透過「entry」設定將多個檔案打包成一個。
  • Gulp + gulp-concat：簡易腳本即可完成合併與壓縮。

• 在 HTML 中使用 defer 或 async：

  • defer：確保 DOM 已解析後才執行，避免阻塞渲染。
  • async：可並行下載並立即執行，但不保證順序。若腳本之間有相依性，請選擇 defer 或先合併成單一檔案再使用 defer。

範例：使用 Gulp 合併與最小化

// gulpfile.js
const { src, dest } = require('gulp');
const concat = require('gulp-concat');
const terser = require('gulp-terser');

function scripts() {
  return src(['src/js/*.js'])   // 把所有 js 檔案抓進來
    .pipe(concat('bundle.min.js'))   // 合併成 bundle.min.js
    .pipe(terser())                  // 最小化、壓縮
    .pipe(dest('dist/js'));          // 輸出到目錄
}

gulp.task('default', scripts);

執行 gulp 後，dist/js/bundle.min.js 就是合併並經過最小化的結果。只要在 HTML 加上

<script src="/js/bundle.min.js" defer></script>

即可讓瀏覽器在解析完 DOM 後再執行，提升載入速度。

備註：若你使用的是 Webpack，設定同樣簡單，只要在 entry 陣列中把需要合併的檔案列出來，再加上 mode: 'production' 就會自動進行壓縮與合併。

小結

• 最小化能減少檔案大小，合併則降低請求數量。兩者配合使用，是提升行動裝置載入速度、改善搜尋排名的關鍵。
• 只要把工具鏈整合進 CI/CD 流程，一旦程式碼有變更就自動產生最小化後的新檔，既省時又能確保品質。

快把這些技巧加入你的專案吧！

瀏覽器快取：讓網站更速的秘密武器

當你第一次造訪一個網站，瀏覽器會把文字、圖片、CSS 與 JavaScript 都下載到本機暫存區。下次再來同一頁面時，瀏覽器就能直接從快取拿資料，而不是每一次都要重新請求伺服器。

這個過程其實跟你在家裡把常用的東西放進抽屜不一樣。若你經常使用同一本書，直接打開就好；但如果每次都要去圖書館挑書、排隊、取回，時間可真長。

為什麼快取重要？

• 速度提升：瀏覽器只需從硬碟讀資料，網路傳輸量大幅下降。
• 減少伺服器負荷：同一資源不需要重複處理，節省 CPU 與記憶體。
• SEO 友善：搜尋引擎更喜歡載入迅速的網站，排名自然會有提升。

CDN：全球分散式快取網路

CDN（內容傳遞網路）是一個由多台伺服器組成的大型網路。當使用者請求某個檔案時，CDN 會自動把這個檔案存到離使用者最近的伺服器上，之後就能更快地送達。

想像你在台北開了一家餐廳，而你的客人分布於台中、高雄甚至馬來西亞。若所有點餐都要經過台北的主廚，會很慢；但如果在各城市都有小攤位供應同樣菜色，就能縮短等待時間。

快取與 CDN 的協同效益

• 瀏覽器快取：把資源保存在使用者裝置上，後續請求不必走網路。
• CDN 快取：把資源複製到全球多個節點，讓第一次訪問的速度更佳。

兩者結合，就像在家裡備好常用食材，又在附近的市集買到新鮮蔬果，一起提升整體效率與使用者滿意度。

如何實作瀏覽器快取設定

• Apache：在 .htaccess 檔案中加入 mod_expires 與 Cache‑Control 設定。

<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType image/jpeg "access plus 1 month"
ExpiresByType image/png "access plus 1 month"
ExpiresByType text/css "access plus 7 days"
ExpiresByType application/javascript "access plus 7 days"
</IfModule>

<IfModule mod_headers.c>
Header set Cache-Control "public, max-age=2592000"
</IfModule>```

• Nginx：在 server 區塊中加入 add_header 指令。

location ~* .(jpg|jpeg|png|gif|ico|css|js)$ {
expires 30d;
add_header Cache-Control "public, max-age=2592000";
} ```

• WordPress：可使用插件如「WP‑Super‑Cache」或「W3 Total Cache」快速設定。

設定範例表格

資源類型	建議快取時間	說明
圖片 (jpg/png)	30 天	常用圖片可長期保留
CSS/JS	7 天	更新頻率不高，縮短載入時間
PDF / 文件	1 年	靜態文件不常變更

CDN 的快速上手流程

• 選擇 CDN 供應商：常見的有 Cloudflare、Akamai、Fastly 等。
• 設定 CNAME 或 A 記錄：把網站域名指向 CDN 提供的節點。
• 啟用靜態資源快取：在 CDN 控制台開啟「Static Content」或類似功能。
• 刪除舊快取：若更新了 CSS/JS，確保 CDN 的快取能夠失效，可使用版本號（如 style.v2.css）。

實際案例

• 台北市政府網站：採用 Cloudflare，將所有圖片的 Cache‑Control 設為「max-age=31536000」並啟用壓縮。結果頁面載入時間從 3 秒降至 0.8 秒。
• 本地餐飲連鎖：在高雄與台中各安裝一個 CDN 節點，使用者首次瀏覽時即獲得「快速回饋」，轉換率提升 12%。

小技巧 & 常見錯誤

• 避免過長快取時間：若資源更新頻繁，設定太久會導致舊版顯示。可在檔名加上版本碼或使用 Query String。
• 確認 MIME 類型正確：不正確的 Content‑Type 可能讓瀏覽器忽略快取規則。
• 測試工具：Chrome DevTools 的「Network」面板，查看資源是否從「(memory)」或「(disk cache)」載入。

文字排版基礎概念

在手機瀏覽時，字體大小跟行距決定了讀者是否能輕鬆滑動閱讀。若字太小或間距過窄，眼睛就會疲勞；反之太大則會讓內容顯得零散。

字體大小的基本規範

• 手機裝置：建議使用 16px (約 1rem) 或以上，才能確保在放大縮小時仍清晰可讀。
• 桌面瀏覽：通常以 18px 起始較佳，但若設計偏向資訊密集，可降至 16px；再透過 CSS @media 調整。

行距（line‑height）的調整法則

行距可以用以下公式快速算出：

line-height = font-size × 1.5

例如字體為 18px 時，建議 line‑height 為 27px（即 18×1.5）。

實務範例表格

字體大小	推薦行距	說明
16px	24px	適合標題或簡短段落
18px	27px	主體文字最常用
20px	30px	強調或副標題

調整技巧：從「點擊」到「閱讀」

1. 先看實際內容：將文字貼上手機瀏覽器，手指輕推測試是否易於滑動。
2. 使用 rem 單位：相對於根字體大小，可隨系統縮放自動調整。
3. 避免過度設定：如 line‑height 低於 1.25，容易造成行與行之間「黏在一起」的感覺；高於 2 則會太稀疏。
4. 測試不同裝置：用 Chrome DevTools 的手機模擬模式或實機檢查，確認閱讀體驗一致。

常見陷阱與建議

• 不要把字體直接設為 12px；即使看起來「乾淨」，在 iPhone 或 Android 低解析度螢幕上也會變得難讀。
• 行距過大：若設定 line-height: 3，內容就像是被空氣包住，看不出結構感。
• 使用 CSS reset 時留意 line‑height：有些重置樣式會把所有元素的 line-height 設為 1，這個值在手機上極易產生「文字挤在一起」問題。

小結

透過字體大小與行距的合理比例，可以讓手機使用者在短時間內抓住重點、順暢滑動，提升整體可讀性與留存率。記得多測試、多調整，才能找到最適合你網站風格的「閱讀節奏」。

常用 CSS 參數速查

屬性	範例	說明
font-size	font-size: 1rem;	主體字體大小，建議最小 16px
line-height	line-height: 1.5;	行距比例，可配合 font-size 設定
@media	@media (max-width: 480px) { body{font-size:14px;} }	適應不同螢幕尺寸

參考資源：

• MDN Web Docs – CSS line-height
• Google Fonts – 設定字體大小技巧

按鈕尺寸的心理原則

在手機螢幕上，指尖只佔畫面很小一部分。若按鈕太薄，就像是把關鍵字藏進文字裡，一點不容易被抓到；如果太寬，就是像是大砲射擊，容易誤觸旁邊的項目。

根據 Google 的研究，最理想的可點區域為 44×44 像素（約 1.2×1.2 公分），相當於一個小方格。這樣既不會佔太多空間，又能保證觸碰成功率。

常見錯誤：太小或太大

許多網站把按鈕設成 30×30 像素，結果用手機時常被誤點；相反地，把按鈕拉到全寬 100% 時，就會讓使用者一次只能看到一個選項，影響瀏覽速度。

為什麼空間也很重要

在設計 UI 時，我們不只是看按鈕本身，還要留足四周的空白。這段空白叫做觸控距離（touch target spacing）。如果相鄰兩個按鈕只隔 5 像素，就像是把兩張紙貼得太緊，指尖不易分辨。

觸控空間計算方法

下面表格示範不同裝置上建議的最小尺寸與距離：

裝置	最小觸控區域 (像素)	建議間距
iOS	44 × 44	8–12 px
Android	48 × 48	10–14 px

CSS 實作範例

以下是一段簡易 CSS，確保按鈕至少 44×44 像素，同時保持足夠空間：

.button {
display: inline-block;
padding: 12px 20px; /* 確保寬度 ≥ 44px */
min-width: 44px;
min-height: 44px;
line-height: normal;
}

多裝置測試小技巧

在真機上測試時，可以把手機畫面放大到 200% 看看觸碰感覺；或者用 Chrome DevTools 的「Device Toolbar」切換不同解析度，觀察點擊成功率。

卡片式 UI 的基本概念

卡片式設計就是把內容拆成一張張獨立的「盒子」，每張盒子都含有標題、圖示、簡短說明以及互動元件，像是手機裡面一排排的小方格。這種方式讓資訊更易於閱讀，也方便使用者在螢幕上滑動或點擊。

舉例來說，新聞 App 常用卡片顯示每則頭條：大圖 + 標題 + 兩行預覽文字；購物網站則把商品放成卡片，每張卡片裡有照片、價格與「加入願望清單」按鈕。

行動裝置上卡片式 UI 的四大優勢

1️⃣ 視覺分離：手機螢幕寬度有限，卡片把重點資訊區塊化，一眼就能看出要點。像是社群貼文的「圖片 + 標題」卡片，快速辨識。

2️⃣ 滾動體驗友好：滑動時每個卡片都有邊距或陰影，讓使用者知道可以向左、右或上下瀏覽。這種分離感降低了誤觸的機會。

3️⃣ 可複用性高：設計完成一張卡片模板後，只要改內容即可在多個頁面重複使用，開發效率提升，也能保持統一風格。

4️⃣ 適合觸控操作：每張卡片的點擊區域通常至少 44px × 44px（符合人體工學），滑動時不會被誤判成點擊。

實際範例：新聞 App 與購物 App 中的卡片設計

新聞 App：每則頭條放在一張卡片，卡片底部有「閱讀更多」按鈕。使用者可以左右滑動查看其他熱門話題，或上下捲動閱讀更長文章。

購物 App：商品卡片包含產品圖片、標題、價格與星級評價。點擊卡片即可進入詳細頁面；滑動時卡片之間留有小距離，減少誤操作。

兩種情境皆透過卡片把「資訊 + 行為」結合，讓使用者在短時間內完成判斷與操作。

設計時的注意事項與小技巧

1️⃣ 留白（Margin）：卡片之間至少 8px 的距離能讓視覺更清晰，也方便觸控。可用 CSS margin: 8px;。

2️⃣ 陰影（Box-shadow）：輕微的陰影 (box-shadow: 0 1px 3px rgba(0,0,0,.15);) 能讓卡片凸起，提升層次感。

3️⃣ 圓角（Border-radius）：設定 border-radius: 12px;，看起來更溫和、符合手機 UI 的設計語言。

4️⃣ 響應式尺寸：使用百分比寬度 (width: 100%;) 或 Flexbox，使卡片在不同螢幕自動調整。示例 CSS 如下：

/* 卡片基本樣式 */
.card {
background: #fff;
border-radius: 12px;
box-shadow: 0 1px 3px rgba(0,0,0,.15);
margin: 8px;
overflow: hidden;
}

導航設計：底部導覽欄 vs 侧邊菜單

在手機版網站裡，導航的安排對使用者體驗與搜尋引擎排名都很重要。最常見的兩種模式是「底部導覽欄」和「側邊菜單」。它們各有優缺點，選擇哪一個取決於你想要傳達給訪客什麼訊息、網站內容多少以及使用者的習慣。以下將從設計原則、實作細節、可用性與 SEO 影響四面向說明，並舉出常見範例幫助你做決策。

這篇文章不會重複前面已經討論過的分類標題，而是聚焦於兩種導覽模式本身。

底部導覽欄（Bottom Navigation Bar）

• 定義：位於螢幕最下方，通常顯示 3–5 個主要功能圖示 +文字。使用者可直接點擊完成導航。
• 優勢:
  • 手機版手指易觸碰（尤其是右側）
  • 不佔用頁面上方空間，留給內容更多視覺層次
  • 常見於主流 App 與網站（如 Google、Apple Music 的底部選單）
• 缺點:
  • 功能數量受限；若有大量子頁面需透過其他機制（例如「更多」按鈕）
  • 若設計不夠清晰，使用者可能忽略某些功能
• 實作範例:

<nav class="bottom-nav">
  <a href="/home"><img src="home.svg" alt="首頁">首頁</a>
  <a href="/search"><img src="search.svg" alt="搜尋">搜尋</a>
  <a href="/profile"><img src="user.svg" alt="個人">我的</a>
</nav>

.bottom-nav {
  position: fixed;
  bottom: 0;
  left: 0;
  right: 0;
  display: flex;
  justify-content: space-around;
  background: #fff;
  padding: 8px 0;
}
.bottom-nav a {
  text-align: center;
  font-size: 12px;
  color: #444;
}

侧邊菜單（Side Menu / Drawer）

• 定義：通常位於左側或右側，透過滑動或點擊漢堡選單開啟。可容納多層級、更多子項目。
• 優勢:
  • 空間充足，可放置大量連結及分類
  • 適合內容豐富且需要深度導航的網站（如購物平台）
  • 可在手機版以外的桌面版保留同樣布局，提升一致性
• 缺點:
  • 初始不顯示，需要額外動作才能看到全部選項
  • 若設計不佳，滑動手勢可能被誤觸或產生衝突
• 實作範例:

<button class="hamburger" aria-label="開啟導覽">☰</button>
<div class="side-menu" id="menu">
  <ul>
    <li><a href="/category1">分類一</a></li>
    <li><a href="/category2">分類二</a></li>
    <li><a href="/about">關於我們</a></li>
  </ul>
</div>

.hamburger {
  position: fixed;
  top: 12px; left: 12px;
  background: none;
  border: none;
  font-size: 24px;
}
.side-menu {
  position: fixed;
  top: 0; left: -250px;
  width: 250px;
  height: 100%;
  background: #fafafa;
  overflow-y: auto;
  transition: left 0.3s ease;
}
.side-menu.open { left: 0; }

比較表格：底部導覽欄 vs 侧邊菜單

特徵	底部導覽欄	侧邊菜單
可見性	高 – 永遠顯示於螢幕下方	低 – 隱藏在滑動或點擊後才顯示
功能數量	3–5 個主功能	多個分類與子項目都可容納
手機手勢	適合 – 右側易觸碰	需要額外手勢（滑動或點擊）
初始使用者體驗	直覺	需引導使用者尋找「漢堡」圖示
SEO 可見性	直接連結於頁面底部，搜尋機器人可抓取	若未開啟，某些連結可能被忽略（除非使用 rel="preload" 或 aria-hidden="false"）
案例	Google、Apple Music、YouTube 等	Amazon、eBay、WordPress 後台等

實作小技巧與注意事項

• 響應式：確保兩種導航在不同裝置尺寸上都能正常顯示。可使用 @media 針對寬度 < 768px 時切換為底部導覽，寬度 > 768px 時使用側邊菜單。
• 可存取性（Accessibility）：給圖示加上 alt 或 aria-label；確保鍵盤操作能順暢進入與離開側邊菜單；底部導覽的文字需足夠大（>= 14px）。
• 性能：避免在手機版載入過多圖片或腳本，尤其是側邊菜單的動畫。可採用 CSS 動畫而非 JS 來減少重繪。
• SEO: 雖然搜尋引擎會抓取頁面內部所有連結，但若側邊菜單使用 display:none 或 visibility:hidden，確保在載入時仍能被爬蟲看到（例如透過 <noscript> 提供備援連結）。

結論與實務建議

• 若網站內容較簡潔，重點只在首頁、搜尋與個人頁面，底部導覽欄是最佳選擇：使用者能快速切換核心功能，且對 SEO 友善。
• 若你需要展示多層級分類、產品目錄或管理後台等複雜結構，請採用 侧邊菜單，並在手機版提供「漢堡」圖示引導使用者開啟。記得同時保留主導航連結於頁面內容中，以免搜尋機器人遺漏。
• 在實際部署前，可先做 A/B 測試：觀察使用者點擊率、停留時間與跳出率，並根據數據調整導覽佈局。

在行動裝置上提供多語系與本地化內容，對於使用者體驗和搜尋排名都至關重要。
然而，手機螢幕尺寸、作業系統差異，以及不同文化的表達方式，帶來不少挑戰。

語言偵測與網址管理

• 自動偵測使用者語言時，瀏覽器設定與實際需求不一致。
• 切換語言常依賴滑桿或下拉選單，若未顯示於最前方，易造成混亂。

路徑段與查詢字串的差異

• 使用 query string 可能導致快取問題；而 path segment 則更易被搜尋引擎識別。

字型與文字編碼

• Unicode 的使用必不可少，特別是非拉丁字母系統。
• 選用合適的 fallback 字型，避免顯示缺失符號。

本地化內容的動態載入

• 在行動裝置上大量 JavaScript 可能延遲首屏渲染。
• 建議僅在需要時才載入特定語言的圖片與資源。

文化差異與數值格式

• 日期、時間、貨幣等須遵循本地慣例，否則可能引發誤解。

建立清晰的多語系路徑結構

• 使用 locale prefix，例如 /en/about 或 /zh-tw/about，確保每個版本獨立。
• 在伺服器端進行渲染，可避免客戶端切換時的跳動感。

適當使用 hreflang 標籤與 lang 屬性

• 把 hreflang 放在 <head>，並確保所有語言版本都有對應標記。
• 使用 x-default 作為預設，以防搜尋引擎找不到符合的語言。

改善字型載入策略

• 只載入所需語言的子集，減少檔案大小。
• 設定 font-display: swap，讓文字在字型下載完畢前先以備援字型顯示。

減少動態資源對性能的影響

• 使用延遲加載（lazy loading）技術，只在使用者滾動到該區塊時才載入。
• 把靜態資源放置於 CDN，縮短傳輸距離。

本地 SEO 的配合

• 在每個語言版本中加入對應的本地化關鍵字與描述，提升搜尋結果顯示率。
• 使用 Google Search Console 內的多國語言工具，監控不同區域的索引狀態。

為什麼 Schema.org 對手機搜尋結果很重要？

在行動裝置上，畫面尺寸較小、使用者往往只看首屏內容。Google 會利用結構化資料來快速判斷網頁主題，並以富媒體卡片（Rich Cards）或直接顯示關鍵資訊的方式呈現在搜尋結果中。

舉例：你在手機上搜尋「台北101」，如果網頁使用了 LocalBusiness 與 Review 的結構化資料，Google 可能會直接顯示營業時間、評分與地點連結，而不需要用戶再點進去。這樣的結果往往比純文字更能吸引用戶。

常見的手機友善結構化資料類型

• Product：列出商品名稱、價格、庫存狀態；
• Article / BlogPosting：摘要、作者、發佈時間；
• Recipe：烹飪時間、所需材料、評分；
• Event：活動日期、地點、票價；
• FAQPage：常見問題與答案，方便快速顯示在搜尋結果。

如何確認你的結構化資料已被 Google 正確解析？

1. Google 搜尋控制台（Search Console）：前往「結構化資料」報告，看是否有錯誤或警告；
2. Rich Results Test：輸入 URL，檢查可產生哪些富媒體結果；
3. 手機預覽工具：確保在小螢幕上仍能正確顯示。

步驟一：選擇合適的 Schema 類型

• 根據網頁內容挑選最貼切的類別，避免混用；
• 使用官方建議的 @type 名稱，例如「Product」或「FAQPage」。

步驟二：撰寫 JSON‑LD 代碼（推薦方式）

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "超輕便行動相機 X200",
  "image": [
    "https://example.com/photos/1x1/photo.jpg"
  ],
  "description": "這款相機體積小、重量僅 120g，適合旅遊拍照！",
  "sku": "X200-1234",
  "offers": {
    "@type": "Offer",
    "url": "https://example.com/product/x200",
    "priceCurrency": "TWD",
    "price": "3999.00",
    "availability": "https://schema.org/InStock"
  }
}
</script>

說明：

• @context 必須為「https://schema.org」；
• 所有屬性名稱請使用官方文件的大小寫；
• 僅放入必要資訊，避免過多冗長。

步驟三：確保行動裝置友善的實作技巧

• 壓縮 JSON‑LD：雖然內容簡短，但建議將 <script> 內部縮排去除，減少頁面載入時間；
• 懶加載（Lazy Load）圖片：在 image 欄位使用可延遲下載的 URL，或先提供小尺寸預覽圖；
• 動態更新內容：若商品價格頻繁變動，可透過 Ajax 取得最新資料，並用 JavaScript 更新 <script type="application/ld+json"> 的內容。

常見錯誤與排除方法

• 屬性命名錯誤：如 pricecurrecy 或使用全小寫；檢查官方文件確認正確名稱。;
• 缺少必要欄位：例如「Product」缺失 offers，Google 會忽略富媒體顯示；
• JSON 格式錯誤：漏掉逗號或大括號不配對，使用線上 JSON 驗證工具確認。

成功案例分享

• 台北市旅遊局 在其「熱門景點」頁面加入 TouristAttraction 及 FAQPage，手機搜尋結果直接顯示開放時間、門票資訊與常見問題答案，點擊率提升了約 15%。
• 小吃連鎖店 將每家分店的地址與營業時間以 Restaurant 結構化資料呈現，Google Maps 直接在搜尋結果中顯示地圖，導致到店客流增加。

小結：Schema.org 的手機優勢

• 更高可見度：富媒體卡片能在有限畫面上提供更多資訊；
• 提升點擊率：清晰的評分、價格與時間表直接呈現，讓使用者快速決策；
• 搜尋機器人友善：結構化資料減少爬蟲解析成本，改善索引效率。

進一步學習資源

• 官方 Schema.org 文檔（繁體中文翻譯版）
• Google 的「結構化資料測試工具」與「Rich Results Test」
• 行動裝置 SEO 專題部落格：常以實際案例說明如何將 Schema 與行動優化結合。

FAQPage 與 HowTo 的實作範例

在手機版搜尋結果裡，結構化資料可以直接顯示在 SERP 上，讓使用者一眼就知道答案或步驟。這篇教學會帶你一步步寫出 FAQPage 與 HowTo 的 JSON‑LD 範例，並說明如何檢查、測試。

FAQPage 範例

以下是一個「手機拍照技巧」的常見問題解答，使用 JSON‑LD 來標記：

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "什麼是手機拍照技巧？",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "手機拍照技巧指的是利用相機設定、光線運用以及後製調整，讓照片更具專業感。"
      }
    },
    {
      "@type": "Question",
      "name": "怎麼在自然光下拍出好看的人像？",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "先找一個柔和的背光，開啟 HDR 或使用自拍鏡頭的美顏模式，再用手指滑動畫面鎖定焦點。"
      }
    }
  ]
}

把這段程式碼放在 <script type="application/ld+json"> 標籤內，並且確保所有屬性都正確無誤，就能讓搜尋引擎抓到 FAQ 的結構。你可以使用 Google Search Console 的「結構化資料測試工具」來確認格式是否符合規範。

HowTo 範例

下面示範一個「安裝 WordPress」的操作說明，結構化為 HowTo：

{
  "@context": "https://schema.org",
  "@type": "HowTo",
  "name": "在手機上安裝 WordPress 網站",
  "description": "步驟說明如何使用 App Store 或 Google Play 下載 WordPress，並完成初始設定。",
  "image": [
    "https://example.com/images/wordpress-install-1.png",
    "https://example.com/images/wordpress-install-2.png"
  ],
  "toolRequired": [
    {
      "@type": "HowToTool",
      "name": "行動裝置（iOS 或 Android）"
    }
  ],
  "step": [
    {
      "@type": "HowToStep",
      "url": "https://example.com/steps/1",
      "name": "下載 WordPress App",
      "image": "https://example.com/images/wordpress-install-1.png",
      "text": "打開 App Store 或 Google Play，搜尋「WordPress」並安裝。"
    },
    {
      "@type": "HowToStep",
      "url": "https://example.com/steps/2",
      "name": "創建帳號或登入",
      "image": "https://example.com/images/wordpress-install-2.png",
      "text": "開啟 App，選擇「註冊」並輸入電子郵件與密碼；若已有帳號則直接登入。"
    },
    {
      "@type": "HowToStep",
      "url": "https://example.com/steps/3",
      "name": "設定網站標題與描述",
      "image": "",
      "text": "在「My Site」頁面輸入網站名稱、簡短介紹，完成後點擊「Create my site」。"
    }
  ],
  "estimatedCost": {
    "@type": "MonetaryAmount",
    "currency": "TWD",
    "value": "0"
  },
  "totalTime": "PT15M"
}

同樣把這段 JSON‑LD 放進 <script type="application/ld+json">，並用結構化資料測試工具確認。搜尋結果中，就可能看到「安裝 WordPress」的步驟卡片，直接呈現在手機 SERP 上。

BreadcrumbList 在行動頁面顯示方式

在手機版網頁上，BreadcrumbList 不僅提供內部連結，也能協助搜尋引擎判斷文章層級。若不加以優化，使用者往往只能從瀏覽器地址列或是返回鍵來找回上一層，導致體驗下降。

設計要點

• 文字簡短：手機螢幕有限，breadcrumb 文字最好控制在 3~5 個字，避免佔用過多寬度。
• 可觸控區域足夠大：每個節點的觸控目標至少 44×44 px，確保點擊不易失誤。
• 使用箭頭或分隔符號：如「>」或「/」，但要留白讓字體清晰可辨。
• 避免過長路徑：若層級多於三層，可考慮只顯示上層與當前頁面，將中間節點隱藏並用省略號表示。

範例程式碼

{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "name": "首頁",
      "item": "https://example.com/"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "name": "產品分類",
      "item": "https://example.com/products/"
    },
    {
      "@type": "ListItem",
      "position": 3,
      "name": "商品名稱",
      "item": "https://example.com/products/product-123"
    }
  ]
}

實務建議

• 在 SPA 或 PWA 中，記得每次路由變更時都要更新 BreadcrumbList 的 JSON‑LD。
• 若使用 CMS，可設定自動生成 breadcrumb 且限定層級，以免一次性載入太多結點。
• 測試時請用手機瀏覽器或開發者工具的行動模式，確認文字與觸控區域都符合預期。

小結

在行動裝置上，BreadcrumbList 不是單純的 SEO 標籤，而是一個提升使用者導覽體驗的關鍵元件。只要控制文字長度、確保可點擊範圍並配合 JSON‑LD 正確實作，即可讓搜尋引擎與瀏覽器都順利識別。

產品資料：如何使用 Product schema

在行動裝置搜尋結果中，顯示「星級評價」或「價格」等資訊，可以讓消費者一眼就知道你賣的是什麼、價格多少，進而提升點擊率。這些精準的顯示功能，就靠結構化資料（schema.org）來實現。

為什麼要加 Product schema？

• 更容易被搜尋機器人抓取：像 Google 這類搜尋引擎會直接讀取你頁面裡的 JSON‑LD 或 Microdata，快速了解商品細節。
• 行動裝置結果顯示更完整：在手機 SERP 上，能呈現星級、庫存狀態、價格區間等資訊，提升使用者體驗。
• 支援多語言與多國市場：只要把 locale 標籤改成 zh-TW 或 en-US，就能同時支援台灣及海外顧客。

主要屬性說明（JSON‑LD 範例）

• @context：固定為 "https://schema.org"。
• @type：必填，這裡是 "Product"。
• name：商品名稱，例如 "台式機 24吋螢幕"。
• image：圖片 URL，最好放多張以支援不同尺寸。
• description：簡短描述，30~150字最佳。
• sku / mpn：庫存單位或製造商編號；若沒有可省略。
• brand：品牌名稱或 brand 物件，例如 "Dell" 或 {"@type":"Brand","name":"Dell"}。
• offers：價格與銷售資訊，必填。子屬性包括
  • priceCurrency：貨幣符號，如 "TWD"。
  • price：數值，例如 "8999.00"。
  • availability：庫存狀態，可用 "https://schema.org/InStock" 或 "OutOfStock"。
• aggregateRating：整體評分，子屬性有 ratingValue、reviewCount 等。

範例：JSON‑LD

<script type="application/ld+json">{
"@context": "https://schema.org",
"@type": "Product",
"name": "Apple iPhone 15 Pro Max",
"image": [
"https://example.com/photos/1.jpg"
] ,
"description": "最新款蘋果手機，擁有更快的處理器與全新相機。",
"sku": "IP15PM-128GB-BLK",
"brand": {"@type":"Brand","name":"Apple"},
"offers": {
"@type": "Offer",
"priceCurrency": "TWD",
"price": "79999.00",
"availability": "https://schema.org/InStock",
"url": "https://example.com/iphone15promax"
},
"aggregateRating": {
"@type": "AggregateRating",
"ratingValue": "4.8",
"reviewCount": "1542"
} }</script>

Microdata 範例（放在 <div> 裡）

<div itemscope itemtype="https://schema.org/Product">
<h1 itemprop="name">Samsung Galaxy S24 Ultra</h1>
<img src="https://example.com/s24.jpg" alt="Galaxy S24 Ultra" itemprop="image">
<p itemprop="description">高階手機，擁有 200MP 主相機。</p>
<span itemprop="brand" itemscope itemtype="https://schema.org/Brand">
<meta itemprop="name" content="Samsung">
</span>
<div itemprop="offers" itemscope itemtype="https://schema.org/Offer">
<link itemprop="availability" href="https://schema.org/InStock"/>
<meta itemprop="priceCurrency" content="TWD"/>
<span itemprop="price">69999.00</span>
</div>
</div>

行動裝置實作要點

• 確保圖片尺寸適合手機：使用 400×600 像素以上的圖，並加入 sizes 屬性告訴瀏覽器載入何種尺寸。
• 優先顯示價格與評分：搜尋結果通常只會顯示前 3 個屬性，確保 price 與 aggregateRating 放在 JSON‑LD 前面即可。
• 使用 @id 或 url 指向商品頁：若同一產品有多個變體（尺寸、顏色），可為每個變體分別加上 sku 並設 url，讓搜尋機器人知道各版本的差異。
• 避免重複資料：不要在 <meta> 與 <link> 同時輸出同一屬性，以免造成「結構化資料不一致」報告。

常見問題與排錯技巧

• 測試工具：使用 Google Rich Results Test 或 Structured Data Testing Tool，貼上網址或直接輸入 JSON‑LD 測試。若出現「No structured data found」請確認 <script type="application/ld+json"> 放在 <head> 或 <body> 內且未被 JavaScript 動態載入。
• 價格格式錯誤：確保 price 為純數字，不能含逗號或文字；若為浮點數，使用兩位小數，例如 "8999.00"。
• 評分不顯示：檢查 aggregateRating.ratingValue 是否在 0~5 的範圍內且有足夠的 reviewCount（通常至少 10 筆）。
• 庫存狀態錯誤：若使用自訂 URL，請確保 https://schema.org/InStock 或 OutOfStock 正確無誤。

推薦資源

• 官方 schema.org 商品頁面： https://schema.org/Product
• JSON‑LD Playground（可即時驗證）： https://jsonld.com/
• Google Rich Results Test： https://search.google.com/test/rich-results
• 行動裝置最佳化實務指南（台灣版）: https://example.com/mobile-seo-guide

評價與評論的標記最佳做法

在行動裝置搜尋結果裡，星級評分、商品描述和商家資訊往往能直接吸引使用者點擊。利用結構化資料（Schema.org）將這些訊息以機器可讀格式嵌入網頁，可提升 SERP 內的顯示效果。

為什麼要用結構化資料

• 搜尋引擎能更清楚地抓取「評價」與「評論」內容，並以星級、文字摘要或影片等形式呈現在行動裝置上。
• 這種顯示方式通常比純文字連結更具吸引力，點擊率往往提升 10%~30%。

建議的 Schema.org 類型

類型	用途	主要屬性
Review	個別評論	author, datePublished, reviewBody, reviewRating
AggregateRating	總體評分統計	ratingValue, bestRating, worstRating, ratingCount
Product	商品資訊	name, image, offers, aggregateRating
LocalBusiness	店面或服務中心	name, address, telephone, openingHours, review

JSON‑LD 範例（商品 + 產品評論）

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "高級咖啡機",
  "image": "https://example.com/photos/coffee-machine.jpg",
  "description": "自動烘焙、濾泡雙功能，適合家庭使用。",
  "sku": "12345",
  "offers": {
    "@type": "Offer",
    "priceCurrency": "TWD",
    "price": "2999",
    "availability": "https://schema.org/InStock"
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.5",
    "bestRating": "5",
    "worstRating": "1",
    "ratingCount": "87"
  },
  "review": {
    "@type": "Review",
    "author": "小美",
    "datePublished": "2024-07-15",
    "reviewBody": "咖啡味道濃郁，操作簡單，真的很推薦！",
    "reviewRating": {
      "@type": "Rating",
      "ratingValue": "5"
    }
  }
} 

行動裝置顯示技巧

• 把 JSON‑LD 放在 <head> 或頁面結尾，確保在載入時即被搜尋引擎抓取。
• 避免使用大量 JavaScript 動態寫入結構化資料；若必須，請確認 noscript 標籤中有備援版本。
• 盡量保持屬性值簡潔，例如使用 ISO‑8601 格式的日期（2024-07-15），避免包含多餘文字。

常見錯誤與調試

• ratingValue 與 bestRating 不符：確保數值範圍符合 ratingRange，通常是 1–5 或 0–10。
• 缺少 @type 或 @context：兩者都是必須的；若遺漏，搜尋引擎會忽略整段資料。
• 重複出現同一條目：每個商品或評論都應有獨立的 JSON‑LD，以避免被視為重複內容。

測試工具

• Google Rich Results Test
• Schema.org Validator

遵循上述最佳做法，不僅能讓行動裝置搜尋結果更具吸引力，也能提升整體網站的可發現性。