無論您的學習程度為何，都不太需要介紹 <img> 元素。
1993 年時在 Netscape 推出 (「馬賽克」) 推出，並在 1995 年納入 HTML 規格中，<img> 向來在網路平台中扮演了簡單卻強大的角色。開發人員新增具有 src 屬性的「來源」圖片檔，並在圖片無法顯示或輔助技術要求替代圖片時，提供含有 alt 屬性的文字替代文字。接著，瀏覽器只會執行一項工作：取得並盡快呈現圖片資料。
就大部分網頁程式開發而言，處理圖片並不容易。儘管現代網路較為複雜，但處理圖片的基本原則並未改變：使用適合網路的圖片格式達成相容性、使用合理的壓縮功能來節省頻寬，以及適用於頁面版面配置中圖片空間的尺寸。
正如我們先前的做法，採用固定寬度的版面配置，我們才更認真地反映使用者如何體驗網路，因此讓整個過程變得複雜。設定圖片來源的大小特別容易。假設圖片佔據寬度為五百百像素，且高度為 300 像素，即為指定相同大小的來源圖片。
使用回應式版面配置的圖片
除了靈活的版面配置和使用 CSS 媒體查詢外，「彈性圖片和媒體」是回應式網頁設計的三大面向之一。為了提高圖片的彈性，開發人員開始使用 CSS 將 max-width: 100% 設定為圖片 (或整個網站的所有圖片)，指示瀏覽器的轉譯引擎，避免圖片縮小到其父項容器。從視覺上來說，這個做法完美地將光柵圖片縮小，看起來流暢無比。如果使用 CSS 的一行或兩行，縮小後的圖片會一直看起來像我們已指定該大小要顯示的圖片來源。如果轉譯引擎收到的圖片資料超過版面配置中佔用的空間，轉譯引擎就能做出明智的決定，判斷如何算繪縮小的圖片，而且不會導入任何視覺構件或進行模糊處理。
通常不會想要「放大」圖片，也就是以大於來源圖片內建函式的尺寸轉譯 <img>。顯示的圖片會模糊不清，且看起來有顆粒狀。
使用 img { max-width: 100% } 表示可以彈性調整容器大小，系統會視情況縮小圖片。不同於設定更嚴謹的 width: 100%，這麼做也能確保圖片在縮放後不會超出其內建大小。長久以來，這已成為處理圖片的規則：使用瀏覽器能夠理解的格式、採用合理的壓縮程度，且圖片絕不會向上擴充。
但就像這樣的做法簡單又有效，結果導致成本高昂。由於 <img> 僅支援單一圖片來源，因此這個方法需要我們提供內建函式 (最大尺寸) 的圖片素材資源。如果圖片佔用了版面配置中空間介於 300px 到 2000px 之間的空間 (視使用者的可視區域大小而定)，圖片來源必須採用內建寬度至少為 2000px 的圖片。如果使用者只透過小型可視區域查看網頁，則所有內容都會正常顯示，圖片的縮放比例也很不錯。在轉譯的頁面中，經過縮小但放大的來源圖片看起來不會與適當大小的圖片不同。不過，系統還是會在傳輸及算繪 2000px 寬幅圖片，透過大量頻寬和處理能力來燒錄，而不會帶來實質好處。
首款「Retina」的裝置問世，由於螢幕「密度」和可視區域大小一樣重要，因此情況顯得更加糟糕。圖片來源需要更大的內建寬度，才能配合高密度顯示。簡單來說，如果螢幕密度是雙倍，圖片像素就會盡可能銳利達兩倍。
在本例中，開發人員再次仰賴算繪引擎的視覺縮小圖片功能。透過在 src 中提供瀏覽器 800px 寬幅來源圖片，然後透過 CSS 指定應以 400px 寬顯示的圖片，結果圖片算繪為像素密度的兩倍：
當然，為了配合版面配置和高密度螢幕的最大可用空間，只有一張來源圖片能以「視覺化方式」的形式運作，供所有使用者使用。顯示在小型且低密度螢幕上的高解析度圖片來源，看起來會與其他小型的低密度圖片看起來一樣，但速度較慢。使用者仍會看到該大型 4000 像素寬圖片來源的所有效能成本，而不致於影響。
長久以來，<img> 大部分都執行了一項操作，那就是「圖片資料無法放到螢幕上」。結果大致上沒問題，但 <img> 並沒有趕上我們所遇到的瀏覽環境極端變動的任務。雖然回應式網頁設計是主流的開發實務，但瀏覽器在將近 20 年的img效能方面最佳化了將近二十年的執行效能，但對大多數特權使用者來說，內容網頁的圖片一開始就沒有效率。無論瀏覽器要求、剖析及轉譯圖片來源的速度有多快，該素材資源的大小都可能會遠超過使用者需要的尺寸。