You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: src/content/en/2022/http.md
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -113,7 +113,7 @@ With the challenges to HTTP/2 priorities, a new prioritization scheme was needed
113
113
While most of the resource priorities are decided by the browser itself, developers can now also use the new <ahreflang="en"href="https://web.dev/priority-hints/">priority hints</a> to tweak the priority of a particular resource. Priority hints can be specified via the `fetchpriority` attribute in the HTML. For example, suppose that a website would like to prioritize a hero image, it can add `fetchpriority` to the image tag:
114
114
115
115
```html
116
-
<imgsrc="hero.png"fetchpriority="high" />
116
+
<imgsrc="hero.png"fetchpriority="high">
117
117
```
118
118
119
119
Priority hints can be very effective in improving user experience. For example, <ahreflang="en"href="https://www.etsy.com/codeascraft/priority-hints-what-your-browser-doesnt-know-yet">Etsy conducted an experiment</a> and observed a 4% improvement in Largest Contentful Paint (LCP) on product listing pages that included priority hints for certain images.
@@ -158,7 +158,7 @@ Given the challenges to using HTTP/2 Push, and it's deprecation from Chrome, dev
158
158
Developers can use Preload as one alternative to pre-emptively request a resource that will be used later in a page load. This is enabled by including[`<link rel="preload">`](https://developer.mozilla.org/docs/Web/HTML/Link_types/preload) in the `<head>` section of the HTML. For example:
Copy file name to clipboardExpand all lines: src/content/en/2022/mobile-web.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -213,7 +213,7 @@ Pages that fail the audit generally have more than one failing link. The median
213
213
214
214
### Zooming and scaling
215
215
216
-
Mobile devices have become a big part of daily life for most people, and the expectation is that interaction with mobile web content should be quick and easy. How websites handle zooming and scaling can go a long way to improving interactions on mobile. There are different takes on this, and while most will agree that you need to set a proper initial scale in the viewport for mobile users (`<meta name="viewport" content="width=device-width, initial-scale=1">`), there is not universal agreement about the second part of a viewport setting, which controls if you should or shouldn’t disable scaling and zooming (`…user-scalable=no" />` or perhaps `…user-scalable=yes" />`). Most authorities, <a hreflang="en" href="https://www.w3.org/WAI/standards-guidelines/act/rules/b4f0c3/proposed/">including the W3C</a>, suggest that restricting scaling and zooming can create a bad user experience and adversely impact accessibility, so it should be avoided. Settings for `minimum-scale` and `maximum-scale` can also be set, and these are often safer limits, if a developer believes that limits are needed.
216
+
Mobile devices have become a big part of daily life for most people, and the expectation is that interaction with mobile web content should be quick and easy. How websites handle zooming and scaling can go a long way to improving interactions on mobile. There are different takes on this, and while most will agree that you need to set a proper initial scale in the viewport for mobile users (`<meta name="viewport" content="width=device-width, initial-scale=1">`), there is not universal agreement about the second part of a viewport setting, which controls if you should or shouldn’t disable scaling and zooming (`…user-scalable=no">` or perhaps `…user-scalable=yes">`). Most authorities, <a hreflang="en" href="https://www.w3.org/WAI/standards-guidelines/act/rules/b4f0c3/proposed/">including the W3C</a>, suggest that restricting scaling and zooming can create a bad user experience and adversely impact accessibility, so it should be avoided. Settings for `minimum-scale` and `maximum-scale` can also be set, and these are often safer limits, if a developer believes that limits are needed.
217
217
218
218
Zooming can be a good workaround for a user who is visually impaired, or anyone who just doesn’t have their reading glasses handy when they need them. On the other hand, it can be hard to build sites that universally scale well on mobile. There are many different font size settings that would need to be accommodated, and getting it wrong can make the site much harder to interact with. This is why some designers prefer to prevent scaling and zooming, to ensure that the page renders in a highly predictable way that is not impacted by scaling and zooming. While this is true, disabling zooming and scaling impedes the usability of a mobile site, and thus, should be avoided for the sake of accessibility.
0 commit comments