發表文章

用CSS簡單寫出漸層色的邊框與圓角(Gradient Border and Radius)

圖片
我們只要用很古老以前就存在的 border-image-source 和比較新的漸層語法 conic-gradient 互相結合就可以辦到。 簡單的漸層邊框範例 #example-card{ width: 200px; height: 200px; border: 20px solid hsl(80 100% 50%); border-image-slice: 1; border-image-source: conic-gradient( from 0deg, hsl(80 100% 50%), hsl(200 100% 60%), hsl(80 100% 50%) ); } EXAMPLE 因為 conic-gradient 的關係,這裡只要注意不要用在 IE 和舊 edge 就可以了。如果還是很擔心,其實用 linear-gradient 也可以。 邊框圓角 大家都知道,漸層屬性的CSS是寫在「xxx-image」底下(這裡是 border-image),而此屬性的 border-radius 會失效。因此,若要實現圓角就必須使用其它方法實現,這裡我們用擁有裁切功能的 clip-path。 clip-path: inset(0 round 24px); inset 的意思是內部裁切,0 是貼合主體,這樣就能簡單實現外邊框圓角。

無限滾動(Infinite Scrolling)對網站SEO的影響

圖片
最近遇到一個要讓 blog 文章無限滾動的要求,也就是說使用者在滾動到網頁下緣的時候,JavaScript 會自動戴入一篇相關的新文章在網頁中,目的是讓使用者繼續觀看相關的內容,增加在網頁的互動時間。 我使用的語法是 Intersection Observer API 和 replaceState,與後端互動的語法則是 jQuery 的 ajax。 Googlebot 會抓取無限滾動的內容嗎? 答案是:會。 至於會抓到多深?根據我自己的觀察,可以抓到至少兩篇無限滾動後出現的文章,Google 還蠻厲害的。 SEO 出現問題 就在我把程式碼寫上去之後一、兩天,網站的所有文章都開始出現一些 SEO 的問題,甚至到了不得不處理的地步,因為各網頁的排名有很明顯地下降(至少我這種寫法確實會影響 SEO,或許存在著對 SEO 更安全的寫法)。 CLS 無限滾動後出現的內容很明顯會造成網頁的區塊位移,我想這大家應該都可以理解,但業主認為這是小問題。而對於業主的「目標」,我也不否認這是可以忽略的問題。 載入時間 若無限滾動後出現的文章容量大小不大,這不會是什麼問題,但就是有容量很大的文章。 我不知道無限滾動後才出現的內容算不算在 Google 的載入時間中,所以我只能說無限滾動可能會讓載入時間受到影響。 結構化資訊錯誤 因為有許多文章使用例如 FAQ 的結構化資訊(FAQ 規定一個網頁只能出現一次),所以理所當然地,Google Search Console 馬上就發出了錯誤訊息通知。 這個問題對我來說是無法無視的,因為這會讓被認定為有語法錯誤的文章的 FAQ 結構不會出現在 SERP 之中。 解決方法 目前是在外面包一層用來偵測 search bot 的程式碼來規避。短期看起來是有效的,因為網頁又回到原本的排名。 var botPattern = "(/bot|google|baidu|crawler|spider|duckduck|crawling|bing)"; var regexp = new RegExp(botPattern, 'i'); var userAgent = navigator.userAgent; if (!regexp.test(userAgent)){ // infinit...

在Search Console指定國際目標的地理定位,會影響網站排名

圖片
如果你的網站客群是全世界,那麼在 Google Search Console 的國際地理定位選項可能會影響網站在搜尋結果 SERP 的排名表現。 網站如何指定國際目標? 該功能在「舊版工具和報表」之中,點開就可以看到「 指定國際目標 」。點擊進入後,在第二個頁籤(國家/地區)可以選擇要不要開啟與定位在哪裡。 而第一個頁籤「語言」,可以檢查網站的 hreflang 標記有沒有錯誤。 但是,如果網站的域名是 .tw 結尾,那麼該系統會自動幫你的網站定位為「台灣」,連選擇的權利都沒有。 地理定位如何影響網站排名? 在 Google 的 SEO Office Hours 影片 中,有人問 John Mueller 為何一個較小的姊妹網站,排名比他們的主要新聞網站還要好。 John Mueller 回答可能是 Search Console 的國際定位設定的問題: 「我注意到的一件事是您在 Search Console 中設置了巴基斯坦的地理定位。我不知道這是否是設計使然,又或是您刻意設定的。如果您想製作一個國際通用的英文新聞網站,那麼關閉地理定位可能是有意義的。在搜尋方面,如果你想定位巴基斯坦以外的國家,比如一般的英語新聞網站,那麼我肯定會關掉它。因為它會較為專注於巴基斯坦的搜尋,然後稍微少關注其他國家。」 結論 所以,以 John Mueller 說的話,再加上該功能的設定特性,在一開始買網域名稱的時候,就已經要確定網站的定位了!? 是要專注在一個地方經營,還是往全世界經營;如果主要目標是在台灣的排名,選擇 .tw 網域或指定地理位置很好;但它可能會對其他國家/地區的排名產生較不利的影響(曝光會少一些),在一開始就要想清楚。

有時候可以用matchMedia當resize的替代方案

圖片
matchMedia 的易用性 JavaScript 語法中的 matchMedia 瀏覽器相容性很高,IE10 以上都支援,所以基本上不用擔心什麼 polyfill。 而 matchMedia 的用法就像寫 CSS 的 media query 或 HTML 的 picture 一樣: var xsMQ = window.matchMedia('(min-width: 480px)'); var mdMQ = window.matchMedia('(min-width: 992px)'); 變數 xsMQ 和 mdMQ 是 boolean 值 ,因此,可以用判斷式來做想做的事。 matchMedia 與 change 事件結合 我們都知道 resize 有效能問題,需要用 debounce 或 throttle 解決,而如果把上述的 matchMedia 判斷式寫成 function,更可以用 change 事件 做到 resize 可以做的事! function mediaQueryStep(){ if(xsMQ.matches){ if(mdMQ.matches){ // big size:do something... }else{ // between big and small size:do something... } }else{ // small size:do something... } } xsMQ.addEventListener('change', mediaQueryStep); mdMQ.addEventListener('change', mediaQueryStep); mediaQueryStep(); 所以,在一些media query 沒有每改變 1 pixel 就會觸發某事件的情況下,matchMedia 也不失為一個好選擇。

Chrome和Edge在網址列打上網域加空格,會觸發站內搜尋功能

圖片
最近才在上方的網址列發現站內搜尋這個功能…… 網址列站內搜尋功能展示 操作方法 只要在網址列輸入該網域後,再空一格就會出現站內搜尋的功能;而且,就算是使用 Google CSE 的站內搜尋網站也會出現。但是,並不是每個網站都能這麼順利出現這個功能。 輸入後出現的搜尋結果頁面 網站實裝猜測 我自己原本猜測是跟 WebSite 這個結構化資訊或使用者本身常不常去有關,但就算有設定也常去了,也不見得百分之百會出現這個功能,所以 chrome 的依據到底是什麼其實沒那麼肯定。 站內搜尋結構化資料 站內搜尋的結構化資料範例如下,其本上每個網站只有 url 和 target 欄位值不一樣而已,但要注意只需加在網站首頁就好了,不要每一頁都加。 { "@context": "https://schema.org", "@type": "WebSite", "url": "https://test.example.com", "potentialAction": [{ "@type": "SearchAction", "target": "https://test.example.com/search?q={search_term_string}", "query-input": "required name=search_term_string" }] } 你也可以看 Google 寫的 網站連結搜尋框 ,基本上大同小異。 有了這個設定,說不定還能在 SERP 出現搜尋欄,雖然一樣是不一定會出現,但怎麼想都賺。 Firefox 的建議網頁 順帶一提,如果使用一樣的方式在 Firefox 網址列操作的話,跟 Chrome 不同,會出現「建議網頁」。 Firefox 網址列的建議網頁

「提供 next-gen 格式的圖片」是什麼意思

圖片
如果你在改善網站速度,對這句話想必一定很眼熟(沒錯,就是 PageSpeed Insights),但到底什麼是 next-gen?簡單來說就是 WebP、AVIF、JPEG2000、JPEG XR 等格式的圖片。 WebP WebP 目前是這四種格式中支援度最廣的格式,且支援去背和透明度。 它除了 IE11 之外,基本上都支援;而 safari 則要看版本夠不夠新(macOS 11)。 WebP 的瀏覽器支援度 另外,它有一個很像的名詞叫 WebM 影片格式: WebM 是一個由 Google 資助的專案(WebP 也和 Google 有關),目標是構建一個開放的、免著作權費用的影片格式檔。該影片格式能提供高品質的影片壓縮以配合 HTML5 使用。( wiki )用途基本上一樣是為了改善網頁載入速度。 AVIF Netflix 聲稱 AVIF 將會是下一代的圖像編碼演算法,並稱它對於他們的影音串流媒體網站而言,是取代 JPEG 格式的最佳選擇。 不過,相較於 2010 年就出現的 WebP,2019 年才誕生的 AVIF 支援度在2023年之後才追趕上來。 AVIF的瀏覽器支援度 JPEG 2000 JPEG 2000 比前兩者更早出現,副檔名是 .jp2 或 .j2c,跟 AVIF 一樣在當年被吹捧成下一代圖像的壓縮標準,但至今幾乎沒有網站在用,也只有 safari 有支援,其它瀏覽器完全不想理它。 JPEG2000 的瀏覽器支援度 JPEG XR、JPEG XL JPEG XR(JPEG extended range)是基於由 Microsoft 所開發的 HD Photo 的圖像格式,所以……基本上只有 IE9~IE11 和舊版本的 Edge 支援。 IE 專屬的 JPEG XR JPEG XL 則發表於 2017 年,但就目前為止的支援度是慘不忍賭,完全沒有瀏覽器支援。 實際運用 基本上,還是要靠 HTML 的 picture 來使用最安全,或者是寫程式判斷瀏覽器支援度,然後載入相對應的圖片格式。個人認為,目前使用 WebP + jpg/png/gif 的應對方式就夠了,頂多再加個 AVIF,但效益如何就自己判斷了。 再來就是 server 端有沒有設定宣告的問題。舉例來說,如果你是用 web.config 設定網站的話...

網站 Favicon 使用 SVG 檔的好處

圖片
什麼是 favicon? favicon 是 favorites icon 的縮寫,中文通常稱為頁面圖示(page icon)或網站圖標(website icon);簡單一點來說,就是瀏覽器最上面各分頁會出現的圖案。 像我這個網站的favicon 是位可愛的吸血鬼 favicon 除了可以用傳統的 ico 檔,也可以用 png 檔,甚至可以用 SVG 檔。 為何要特地用 SVG 檔? 用一般圖檔就好了,何必要再創作一個 SVG 檔呢?因為 瀏覽器有 dark mode 的存在 ,這個模式可能會讓網頁的 favicon 看不清楚,這就是我推薦使用 SVG 檔的原因,因為我們可以很輕易地在 SVG 檔中塞 CSS 語法進去調色,別的檔案格式沒有這種能力。 看到一看就知道沒去背的白底 icon 會讓我很焦慮, 以下為簡單的例子: <svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" x="0px" y="0px" width="64px" height="64px" viewBox="0 0 64 64" enable-background="new 0 0 64 64" xml:space="preserve"> <style> path{fill:#2858aa;} @media (prefers-color-scheme: dark) {path{fill: #23A6DE;}} </style> <path d="example"/> </svg> 「 prefers-color-scheme : dark」就是在 dark mode 下呈現的樣貌,寫法跟 media query 一樣。我們可以在括號範圍內設定一個比較亮的顏色(fill: #23A6DE)才不會讓使用者看不清楚。 favicon HTML 設定 在 HTML 的 head 標籤裡照這樣設...

Google搜尋結果出現縮排網頁(indented),造成排名變動

圖片
在搜尋結果中,某些網頁下面會附帶一個前方空一格的網頁(Indented Results)。這種「縮排」會造成什麼情況?因為它與排名第一才可能會出現的目錄(Sitelinks)不同,也算在搜尋結果排名之中,就把原本排名 9、10 名的網頁擠到第 2 頁去了(預設一頁只有十個搜尋結果)。 什麼情況會產生縮排網頁 多語系且不同網址的相同內容。 與使用者意圖相關的內容。 同網域且在講同一件事的文章。 PDF 其它相關內容? 下面簡單找幾個例子來看: 這2篇文章都在說同一件事,可能因此才附加縮排網頁 sitelinks 和 縮排同時出現 不同子網域出現在縮排的情況,研判是相關內容且對使用者更方便的網頁(一頁式 eDM) 依我的理解,這可能與「搜尋旅程」有關。但是搜尋「mes廠商」的使用者,還需要理解什麼是mes嗎?(在我寫完這篇文章後2天,Google就把它拿掉了) 另外,中文使用者一定較容易看到,繁中或簡中雙語系其一出現在縮排的搜尋結果,例如 wiki、facebook 或其它多語系網站。 還有一種是相同內容,但不同媒介的文章,例如網頁版和 pdf 版。曾遇過 title 與內文一模一樣的 pdf 縮排。 就目前看到的情況是這樣,可能還有其它狀況。 初步實驗 我拿出現不同子網域 B 的縮排網頁當受試者(上面不是縮排的子網域為 A):做一個幾乎跟縮排網頁一模一樣內容的網頁,但放在相同的子網域 A 中,並把原本在 B 的縮排網頁 301 轉址到這個新網頁。 得到的結果是:搜尋結果的縮排網頁消失。 但若搜尋結果本身是首頁的話,縮排網頁會先消失幾天,之後又出現變成 sitelinks 的一份子,然後又消失。 我的看法 所以,Google 對自己在 SERP 選上的網頁沒有自信嗎?居然用這種方式幫本來排名就較強勢的網頁多佔一個名次。 又或者,是在幫重覆內容的網頁解套?雖然 Google 說過重覆內容不會被懲罰,但同個母網域最多只會出現 2 個網頁在搜尋結果的規則,就讓擁有重覆內容的網站管理者傷透腦筋;這種「縮排」一出現反而幫了這些網站大忙, 這讓盡力保持沒有重覆內容的網站情何以堪? 無論如何,會附帶縮排的搜尋結果,或許是 Google 認為該區塊可以讓 使用者的搜尋旅程 短一點。 附上 John Mueller 在 202...

網頁標題在Google搜尋結果會被如何更改?

圖片
有些網頁在 SERP 的標題 <title> 會被 Google 大幅度改寫,而實際的運作機制又是什麼呢?SEO 又是否會被影響? Google 如何生成新的網頁標題: 我們已經知道 Google 會改寫標題的頭尾(把產品或企業名稱加在標題結尾或開頭),但這次的改動比起前者更進一步,可能整句都會被重寫或刪除。 根據 Google 公開的說明頁面 和他們之後提供的 補充說明 可以得知,他們確實在 8 月 16 日推出了新的網頁標題生成系統,並會從該網頁的主視覺標題、一般標題、h1 或 h2 h3 之類的標籤內容,或者使用樣式而變得大而突出的內容,進而產生新的網頁標題文案。 更甚者,可能還會參考頁面中的其他文字、使用指向該頁面連結中的文字,或是自己改年份加項次來「改善」該頁面原本的標題。 但實際上改變不止侷限於 Google 公開的方式,還包含 直接截短 、 刪除句中的某些關鍵字 。用這個網誌來舉例的話,〈簡單理解LCP、FID、CLS三個網站使用體驗核心指標是什麼、對SEO的影響、改善案例〉這篇的標題因為太長了,便會被 Google 截短只剩下〈簡單理解LCP、FID、CLS三個網站使用體驗核心指標是什麼〉。 所以,我們可以簡單歸納出原本和現今的標題改動方式: 在前面或後面加上品牌名。 直接截斷。 截取網頁內容資訊(通常是大標)。 增加搜尋相關關鍵字在標題中。 刪除不必要的關鍵字或行銷術語後重新排列。 改年份或加項次(第1季 第2季)來區別重覆標題。 使用指向該頁面連結中的文字(極少)。 上述情況有時候會同時出現。 順帶一提,Google 認定「品牌名」的方式,經過我自己的實驗是和首頁的 title 大有關聯,另外還會參考各網頁 title 像產品名的重覆字詞。而 title 整體太長的話,除了常見的「...」結尾之外,也可能會直接把品牌名刪除;而比較特別在結尾有「雙品牌」的標題,也見過其中一個品牌名被移到最前面的情況。所以請小心命名,避免關鍵字被當成品牌名的一部分而遭 Google 刪改或移動。 另外,Google 對於品牌名的區隔符號比較偏好「-」而不是「|」,括號也有高機率會被更改。 ...

最大公因數和最小公倍數計算機(多數字)

最大公因數、最小公倍數計算機 請輸入數字 1 和數字 2 之後,按下「計算」按鈕,或新增數字 3、4…,看要計算幾個數字, 就可以得到最大公因數(1,2,...) 和最小公倍數[1,2,...]。 數字 1: 數字 2: 增加輸入框 刪除輸入框 計算

如何產生醒目顯示文字的連結?讓使用者一目瞭然的功能(Scroll to Text Fragment)

圖片
若你在優化任何非網站的網址(Office文件、PDF、留言、Email、Google 我的商家、SERP結構化資料如 FAQ 中的網址),除了在網址使用 #id (錨點)之外,Scroll to Text Fragment 或許是另一個可以考慮的方式。 URL Scroll to Text Fragment 是什麼? 它的功能是在網址中設定文字,使用者點擊網址進入網頁後,可能看到被強調的文字,並將畫面移動到該文字處,文字高度在畫面中間。這並不是什麼新功能,早在 chrome 80 以後就出現在以 chrome 為核心的瀏覽器之中了。 如何創建? 複製醒目顯示文字連結 在 chrome 90 之後的版本,網頁上選取(反白)文字之後按右鍵,就會出現「 複製醒目顯示文字的連結 」的功能,點擊該功能產生的連結,貼到任何除了該連結頁面之外的地方,被點擊後就可以產生上一段文字提到的效果。如果沒有該功能,可能是被設定成關閉,網址列輸入 chrome://flags 並按下enter後,找到 Copy Link To Text 後就能開啟該功能(enabled)。 如何關閉? 但是,在最新版本的 chrome 中, chrome://flags 已經找不到 Copy Link To Text 這個指令了,換句話說就是沒辦法關閉這個功能,還請注意。 文字反白之後右鍵即可看見該功能   連結的架構與DIY 若不想透過 chrome 附加的功能直接設定使用的話,自己也可以設計出這種特殊網址,方法與錨點類似,不過是加上「 #:~:text= 」 完整結構: https://example.com#:~:text=[prefix-,]textStart[,textEnd][,-suffix] 方法1 整段文字: 只使用 textStart 的話是最簡單的使用方式: #:~:text=文字 ,它會當成要 highlight 的所有文字,就像 {這個連接} 的範例一樣。 方法2 文字區段: 你也可以打上兩段文字: #:~:text=文字1,文字2 ,分別代表開頭和結尾,它會找尋這一區段的文字 highlight,這裡也用 {這個連接} 示範一次。 方法3 多段文字: 可以使用「&」區隔: #:~:text=文字1&text=文字2 。但是個人不建議這樣做,畫...

UX = User Exploitation (利用使用者)

圖片
看到一篇 談論1997年至今的 UX 發展 的翻譯文章,原文的作者是Mark Hurst,看完之後心有戚戚焉,推薦給大家一起看,力道雖然沒有「 真正發生過的恐怖IT故事 」強,但也一樣是很無奈的現況。 KORONE FALCON PUNCH 文章從1997年至今分成3個10年去描述 UX 產業的變遷。 UX 的定義已經從原本的 user experience,漸漸被 user exploitation 取代,網站不再以便利性為目標,而是網站擁有者的目的為目標:試圖以各種方式誘導或阻止使用者在網站上做某些事情。 就像中文的「設計」一樣,英文可以翻譯成 design,也可以翻成 calculating。 真實案例 該文用 Amazon Prime 和紐約市疫苗網站為例子: The cancellation procedure is long, and consists of six separate pages. On each separate page, the consumer is nudged toward keeping their Prime membership, even though they have began a procedure to end the agreement. ...This uncertainty is further strengthened by having to scroll through the page, which is full of text and graphics to show how cancelling the membership will mean the loss of many benefits. In the single biggest public health crisis in the world, New York can't build a usable vaccine website. The telephone - 1950s technology - is our best option, after 25 years of web development. Shameful. 從 UX 設計領導者 Amazon 帶頭墮落,默默道...

用CSS的 min max與vw cqi,設計有極限值的RWD響應式文字

圖片
你是否有想過,max/min font size 的解法?能不能單靠 CSS 設計出會自動調整大小的 Responsive Font Size?答案是可以的! 文章目錄: vw 基本運用 極限問題 max()、min()、clamp() container-type與cqi 為何使用 vw? 在編寫 CSS 的時候,你可能習慣將網頁上的字體大小(font-size)使用 rem、em、px 等單位設定,但在講究 RWD 的情況下,甚至是 Google SEO 著重在手機介面的現在,總是會遇到桌機看起來很舒適,但畫面一變小,標題類的字就又太佔版面。 而使用 viewport width (vw) 當作字體大小的單位,就可以讓字體隨著視窗寬度的不同自動縮放其大小。 各瀏覽器支援 vw 的情況 vw 基本運用: vw 是視窗寬度的百分比,所以 1vw = 1%的視窗寬度。舉例來說,當視窗寬度為 1000px 且 font-size: 1.5vw 的時候,字體的大小就是 1000*1.5% = 15px。 h1,.h1{ font-size: 1.5vw; } 除了直接運用之外,也能搭配 calc 使用: h1,.h1{ font-size: calc(10px + 1.5vw); } 極限問題(max or min font size) 這是不管設計什麼東西都存在且必需要考慮的事情,vw 也不例外。 設計網頁一定會設一個網頁寬度,以此寬度設定做為最大值;而人的視力有限,以 16px 當作最小值。所以,當視窗被拉到極大或極小的時候,以 vw 為單位的字體勢必會變成你不想要的樣子,這時候我們就必需設定最大值和最小值,讓字體在合理的區間變動,而 media query 和 min()、max()就出現在解決辦法的清單之中: 以前的做法:Media Query 下面為使用的例子: h1,.h1{ font-size: 3.5vw; } @media (min-width: 1600px) { h1,.h1{ font-size: 40px; } } @media (max-width: 480px) { h1,.h1{ font-size: 16px; } } 這樣子設定...