首先看你的 Chrome 版本，要在 124.0.6367.119 這個版本以上才能使用此功能。不是的話請升級至最新版本。

在 Chrome 登入你的 Google 帳號 (gmail 帳號，youtube 帳號皆相通)。

Google 的 AI 引擎叫做 Gemini，可以先到 Gemini 官網登入一下，待會使用才不會卡在這。登入時大概就是同意隱私權條款之類，完成登入後 Gemini 頁面先擺在那，或是關掉都沒關係。

「先到 Gemini 官網登入一下」這個動作只要第一次打通即可，未來不用再做。

以上都走過了，將來只要你 Chrome 有登入 Google 帳號，在網址列輸入@，就會看到「與 Gemini 對話」的提示，點它。

撰文的現在是2024年5月10日，目前「與 Gemini 對話」後面只能輸入英文，輸入中文轉到 Gemini 網頁時會顯示亂碼。

你可以在「與 Gemini 對話」後面 (網址列) 先隨便輸入簡單的問題，例如：what is the weather in Taipei?

瀏覽器就會轉到 Gemini 頁面，回覆你答案。以上就是在 Chrome 網址列使用 Gemini 的方式。

輸入與回覆中英文的問題

上面提到網址列目前 (2024年5月10日) 只能輸入英文，但很好玩的是，你如果在 Gemini 網頁直接輸入中文是可以的。

如果你用網址列(目前只能輸入英文)，Gemini 預設會回覆你英文。你可以在(英文)問句後面接 respond in traditional chinese，這樣 Gemini 就會回覆你繁體中文。

larry 實際測試，有時候在 Gemini 網頁直接輸入中文，它也會回覆你英文。如果發生此情況，你可以在問句後面接「回覆中文」字樣，Gemini 就會回覆中文。

文字部分的應用

基本上什麼事情都可以問 Gemini。例如什麼人、事、物，旅遊景點與行程。也可以產生文案的範本，你可以藉此找出 idea。或是查詢什麼教學或指引，以上都可以由 AI 協助。

AI 會快速給你一個「導引」(introduction)，讓你至少有起點可以開始搜尋，我覺得這是 AI 最大的功用。

可否產生圖片？

中文目前 (2024年5月10日) 無法產生圖片。用英文測試，larry 有看到兩種結果：有的時候可以產生圖片，有時候 Gemini 會回覆一個連結和縮圖，讓你導到其他網頁 (有你要的圖片)。

即時的新聞與事件，直接Google會比較準

這種生成式AI，還是需要機器學習的時間。當下發生的新聞與事件，只是它學習素材的一部分。

也就是當下發生的新聞與事件，它還來不及學習與整理，沒辦法回覆，或是回覆的是「舊聞」。

我覺得遲疑的點

這種生成式AI，等於是你問它一個問題，它整理出一個短的圖文文章給你。但是我會覺得第一，內容的真實性，真的是這樣嗎？

對比直接 Google 搜尋，是整理出網站列表，可能有官方網站，可能有大媒體公司的網站，可能有點進去圖文真的很詳盡的部落格。

以上這些網站都有或高或低的「權威性」(當然以你喜歡的為主)。但是 AI 直接回覆的圖文，我會覺得：真的是這樣嗎？

再來，深入度 (也跟真實性有關)。例如問AI：台南最好玩的景點。它肯定可以回覆你最「知名」的一些景點。但這些真的是台南在地人會推薦的嗎？或是最新最熱門的嗎？

問事情、問教學也是一樣。larry 覺得這種生成式AI 只能提供你一個「導引」(introduction)，如果你要真正的解答，還是要 google / youtube 每個網站或影片去看。

工具使用之外，我的觀察

英文很重要，機器學習一定是從全世界的「英文」文件、影音開始學習，才會擴展到其他語言。不同的語言又有不同的文法與語意，機器要能理解，沒那麼簡單。

也就是等繁體中文完整上線，已經是英文版上線之後很久的事。所以 larry 會覺得英文還是非常重要，甚至你用英文跟 Gemini 聊天，藉此練習英文也很好。

另外 larry 講一下商業的東西，包含很多知名商業評論與雜誌，多數認為 Google 在 AI 領域落後微軟。但我覺得 Google 用 Chrome 當入口工具，這招很高啊。

網路服務，入口非常重要，包含早年的Yahoo首頁，Google搜尋結果頁，LINE，微信，任何服務搭在這些入口軟體，都很容易成功。

Chrome 瀏覽器壓倒性的市佔，這是事實。Google 用一個絕對優勢的位置，與新的服務 (Gemini) 產生綜效，這是完全正確的決定。

從 Chrome 85 開始，在 Android Chrome 開啟網頁，長壓網頁上的一個連結，如果這個連結的目標網頁是所謂的快速網頁的話，長壓後跳出的小視窗上面會有 “Fast page” 的字樣。

Google 在幾個月前公布，他們以後會以 Core Web Vitals (名稱是Google取的，中文可以翻譯為「網站使用體驗核心指標」) 作為評估網頁品質的一套規範。Core Web Vitals 的細節讀者可以暫時不用研究，大概是包含了網頁的載入時間，行動裝置上的版型，和使用體驗。一個網頁是否為快速網頁，就是 Google 依照 Core Web Vitals 來判斷的。

上方連結的原文中有一段

“Fast page” labelling may badge a link as fast if the URL (or URLs like it) have been historically fast for other users. When labelling, historical data from a site's URLs with similar structure are aggregated together. Historical data is evaluated on a host-by-host basis when the URL data is insufficient to assess speed or is unavailable, for example, when the URL is new or less popular.

快速網頁的判斷是長期累積的資料分析，也就是說，要長期都是快速網頁，才會有 “Fast page” label。如果是新網頁、或是流量不夠的網頁，Google 會依照同一網站類似網頁的數據，來判斷新網頁/流量不夠的網頁是不是快速網頁。也就是說，會有一個全站分數。

Chrome 85 (Android版) 開始有標記快速網頁的功能。如果讀者是 Android 手機，看一下手機裡 Chrome 的版號。也可以長壓任何一個 Wikipedia 連結，測試看看 “Fast page” label 有沒有出現。

Again，工具的使用是其次，我們要了解的是 Google 的態度和方向。目前看來 Core Web Vitals (網站使用體驗核心指標) Google 是會繼續進行下去。這次的 “Fast page” label 網頁載入速度當然也是 Core Web Vitals 的一環，行動版網頁的使用體驗和速度，仍然是 Google 關注的重點。

前幾天 Google Webmaster blog 有一篇文章，再次公告 Chrome 80 (有可能是 2020 二月) 開始預設禁止存取第三方 cookie.
https://webmasters.googleblog.com/2020/01/get-ready-for-new-samesitenone-secure.html

Chrome plans to implement the new model with Chrome 80 in February 2020.

這個 new model 指的就是 cookie 的使用規範。larry 看問題喜歡看問題的本質，什麼叫 cookie, 什麼叫「第三方」cookie, 又為什麼第三方 cookie 有可能的安全性問題？

我們來看 web dev 這篇好文 https://web.dev/samesite-cookies-explained/

什麼叫 cookie?

cookie 就是一筆一筆的資料，由網站或嵌入網站的服務存入用戶的瀏覽器。例如你到 CNN 看新聞，www.cnn.com 就會存幾筆 cookie 到你的瀏覽器，有可能是記錄你的登入登出狀態，瀏覽紀錄等等。嵌入網站的服務大家最熟悉的就是 GA (Google Analytics), GA 一樣是發 cookie 到使用者的瀏覽器，它才能區別你第一次來逛網站，和第二次來逛網站是同一個人 (正確來講是同一個瀏覽器。)

上面 web dev 文章提供一個範例，例如你逛一個購物網站，該網站會發一筆 cookie 給你 (存在你的瀏覽器)

Set-Cookie: promo_shown=1; Max-Age=2600000; Secure

promo_shown=1 是客製化資料 (下次來這個購物網站時跳出促銷訊息)，Max-Age=2600000 指的是 2600000 秒後 (約一個月) 這筆 cookie 會自動失效，Secure 指的是存取這 cookie 需要 https 連線。

當你下次來這個購物網站時瀏覽器會自動送出給該購物網站，所以它知道要跳出促銷訊息

Cookie: promo_shown=1

因為每個網站「不知道」現在連線的是誰，是登入還是登出，用 cookie 可以紀錄使用者狀態，達到好的使用體驗 (例如臉書不用開一個分頁就要登入一次)。

什麼叫「第三方」cookie

網站叫第一方 (瀏覽器網址列顯示的網址叫第一方)，使用者叫第二方，第一方網站嵌入的 code 叫第三方。大家最熟悉的第三方例子就是 GA (Google Analytics), 有一些網站會嵌入臉書的 code, 也是第三方。

為什麼第三方 cookie 有可能的安全性問題

還記得上方跳促銷訊息的例子，當你回到網站，或是再次觸發第三方服務時 (例如 GA)，你瀏覽器會自動送出第一方網站發的 cookie 給第一方網站，第三方發的 cookie 給第三方。

上方 web dev 文章提到，例如網站A 嵌了一個網站B 的圖檔進來，此時網站A 就是第一方，網站B 就是第三方。當你開啟網站A，屬於網站B 的 cookie 也會送給網站B。那如果網站A 是一個惡意網站呢？它不停的用程式去 run 網站B 的連結，照目前的機制，瀏覽器上的 cookie 也會拼命的送給網站B (此時網站B 就算是被攻擊)。網站A 只是一個例子，網路上有無窮無盡的網站有可能是惡意的，網站B 是不是處於風險之中。

了解什麼叫 cookie, 什麼叫第三方 cookie, 又為什麼第三方 cookie 有可能的安全性問題後，我們來看目前 cookie 分為三類

• SameSite=Strict. 此類 cookie 當使用者瀏覽器網址列的網址，等於 cookie 的發行者時 (精確來講是符合 same-site 規則)，cookie 才會被送回去。上述網站A嵌入網站B的圖檔的例子，如果網站B發的 cookie 是 Strict, 使用者開啟網站A 時，屬於網站B 的 cookie 「不會」被送回。
• SameSite=Lax. 在 SameSite=Strict 之外，允許某些低風險的 cross-site cookie。例如點一個外部連結，HTTP method GET 等，可以允許 cross-site cookie 送回。一般來說是網頁會跳轉的情況，但不包含嵌入外部資源。
• SameSite=None. 不看 same-site 或 cross-site，不管哪種 HTTP method，一律送回 cookie。有潜在安全性的問題。也是目前大部分瀏覽器的現狀。

以下是 web dev 文章附的 sample cookie, 有 sample 看起來會比較有感覺

Set-Cookie: promo_shown=1; SameSite=Strict

Set-Cookie: promo_shown=1; SameSite=Lax

Set-Cookie: widget_session=abc123; SameSite=None; Secure

那 Chrome 80 要怎麼改？

1. 如果 cookie 發行者「沒有」指定 SameSite (Strict, Lax, None), 預設為 Lax.
2. 如果 cookie 發行者指定 SameSite=None, 一定要加 Secure, 如上方 sample. Secure 指的是一定要是 https 連線。

那 GA 等第三方服務有沒有影響？

照以上結論，往後第三方服務發行商一定要把自己發的 cookie 加上 SameSite=None, Secure. GA 發的 cookie 由 GA team 來負責，Google Ads 發的 cookie 由 Google Ads team 來負責。我相信 Google 自己出的第三方服務 (GA, Google Ads, 等) 早已準備好了。有影響的是第三方服務發行商，例如智能推薦系統，廣告系統，這些廠商要去確認自己發的 cookie.

上方是 2019 二月份 thinkwithgoogle 的一篇文章，列出了 ok 和不 ok 的廣告

桌機

• 右側 menu 長條形廣告 (Yes)
• 上方大圖廣告 (Yes)
• 頁面 inline 廣告 (Yes)
• 彈出式廣告 (No)
• 倒數特定秒數後才會顯示網頁 (No)
• 大型 sticky ads (黏著在瀏覽器邊邊，不隨 scroll 捲動的廣告) (No)
• 自動播放有聲音的影片 (No)

手機

• 小型上方或下方 sticky ads (Yes)
• 小型 inline 廣告 (Yes)
• 彈出式廣告 (No)
• 大型 sticky ads (No)
• 自動播放有聲音的影片 (No)
• 廣告占網頁面積比超過 30% (No)
• 閃爍及動畫廣告，即使 inline (No)
• 占滿全螢幕，需要不斷 scroll 移除的廣告 (No)

總的來說

• 無論手機桌機，彈出式廣告大概就不行
• 小型 sticky ads ok, 大型 sticky ads 不行
• 自動播放有聲音的影片不行
• larry 覺得占比不能超過 30% 這一項很精髓。有一些同時有小型 sticky ads 和 inline ads 的網站，看似都符合廣告原則，但其實瀏覽體驗極差。占比不能超過 30% 的原則限制了這種情況。

Google 也有提出工具來檢測廣告使用者體驗 https://support.google.com/webtools/answer/7159932

另外依照這篇文章，Chrome 將在今年 (2019) 7/9 開始阻擋不符規範的廣告。
https://blog.chromium.org/2019/01/building-better-world-wide-web.html

Again, 工具的使用倒還是其次，但大家要知道 Google 是有心要處理廣告體驗這件事情。

Google於 4/16 發布的這篇官方部落格文章，larry認為是精彩而重要的
https://webmasters.googleblog.com/2019/04/instant-loading-amp-pages-from-your-own.html

首先，Google 在官方 Webmaster blog 多次提及 AMP 網頁。Google 「並沒有」說支援 AMP 的網頁搜尋結果排名會上升，但多次提及 AMP 網頁，各位老闆可以自行推敲 AMP 網頁是否重要。這篇官方部落格裡有一句

“We believe that privacy-preserving instant loading web content is a transformative user experience”
翻譯：我們相信同時考量到隱私權的快速載入網頁，是一種革命性的使用者體驗。

所以大家可以知道，google對於快速載入網頁這一路會繼續做。再來他提到 AMP 網頁的代價是 (先不論業主所花的工程 cost) URL 裡總是 google.com/amp 開頭，再接你的網址名稱，例如 https://www.google.com/amp/s/your_site.com/your_page_address

google.com/amp 開頭這件事已經有很多客戶/用戶反應 (為什麼不是他們的網址名稱開頭)。在這篇官方部落格 Google 提出一個 solution: Signed Exchange

Google AMP 官網上有一句講得比較清楚
https://blog.amp.dev/2018/11/13/developer-preview-of-better-amp-urls-in-google-search/

“Allow the browser to treat a document as belonging to the publisher's Origin. This allows a publisher to use first party cookies to customize content, execute service workers, and measure analytics.”

他的意思就是說，即使來源 (origin) 是 google.com/amp, 這項新的技術可以讓瀏覽器認為目前這張網頁來源是業主本來的網址 (因為 Google AMP 是抓業主的網頁去 cache, 所以現在來源是 google.com/amp)

舉例來說，業主的 AMP 網頁收錄到 google 後是網址A, 業主的原網頁網址是網址B. 如果網址A和網址B是 Signed Exchange, 當使用者 request 網址A, 瀏覽器顯示的會是網址B, 並且同時網址A的 cookie 和 js code 等都還在運作。

目前 Signed Exchange 技術還在 developer preview 階段，瀏覽器支援也不普及 (尤其是非 chrome 的用戶)。但 Google 往這一路的方向是確定的，實作上 larry 是建議讀者先等這項技術成熟後，再花 cost 實作。