100 points on pagespeed is not that hard with static sites.
- drop 99% of the JS (PWA, lazy-loading, infinite scroll, jquery, you don't need any of them for a webpage), convert the remaining for 1% to vanilla js and use it as progressive enhancement.
- use EM or % as layout width/height
- inline css, js, and svg
EDIT
- no webfonts!
The only thing that'll remain as an issue are tables wider, than viewport, on mobile.
Don't know about PWA. Service workers are pretty lightweight and help with caching.
But yeah, lazy-loading, infinite scroll, etc., are all designed to cover up design flaws that impact performance. I think lazy-loading can be potentially done right, but almost none of us do anything right.
> use EM or % as layout width/height
Why? EM/REM is good for handling font sizes, but for anything else it may not make sense and a custom font setting in the browser can break layouts if the size of boxes are based on font sizes. PX is perfectly adequate for layout, and is actually a relative unit(PX !== hardware pixel). Same for borders, padding, margin, etc. Even REM is better than EM for most cases. People who adjust the font size in their browser don't necessarily want their layout to change and potentially degrade as a result.
> inline css, js, and svg
Can be a good idea, especially if you can somehow identify the CSS used on page load and discard anything nonessential. Though maybe HTTP/2 makes inlining obsolete. IDK
> no webfonts!
Thank you! Web fonts are perfectly sufficient in 99% of cases.
> Why? EM/REM is good for handling font sizes, but for anything else it may not make sense and a custom font setting in the browser can break layouts if the size of boxes are based on font sizes. PX is perfectly adequate for layout, and is actually a relative unit(PX !== hardware pixel). Same for borders, padding, margin, etc. Even REM is better than EM for most cases. People who adjust the font size in their browser don't necessarily want their layout to change and potentially degrade as a result.
I had a lot of bad experience with px, but it is true that for borders it's the only reasonable choice.
REM is not that well supported, especially in awkward browsers (Dillo, for example).
Imo EM is nicer for padding/margin; it keeps the text/layout ratio even if the font is resized, unlike px.
But point taken, it cannot be used as the only unit.
Have you actually tried the site on a mobile device? It's impossible to read the text and navigation is hell. Wouldn't classify that as "mobile friendly".
What do you mean? It has reasonable column width so you can zoom in and out as necessary, often with a double tap. That is, it leaves it up to the client to adjust as necessary -- in contrast with the typical mobile site, which:
1) Forces a particular size/resolution, locking out zoom capabilities
2) Has a floating header with a constant size relative to your device screen, blotting out the same real estate no matter how much you zoom. And, of course, using the same header pixel height for portrait vs landscape, making the latter practically unusable.
Yes, this site is better than 99% of mobile sites out there.
Edit: Some further comments: It's generally better to have a site that obeys the standards and thus plays nice with any client, than one that locks you into the hip designer's meth-addled decision. This site in particular works well with my extensions like VimFX for clicking links from the keyboard.
That's the thing - it shouldn't be necessary. I don't do that on desktop browsers; why should mobile devices be any different? If the site is not legible, I set the desired zoom once and I'm done. There's no need to go back and forth.
Now, I can't do that if the elements stay mismatched on mobile. I have to zoom in and then back when I want to interact with small elements - each time. It gets old when I have to click tiny links or upvote arrows more than a few times. It's jarring and not a good user experience.
> And, of course, using the same header pixel height for portrait vs landscape, making the latter practically unusable.
The floating header issue notwithstanding (I don't like them either), this is exactly why the web designers should tailor their elements to different viewports.
> It's generally better to have a site that obeys the standards
Yes, and that also includes accessibility guidelines. Compatibility with keyboard navigation is one of them, but so is the size and spacing of the controls, links, and buttons.
True. Zooming in shouldn’t be necessary. And mobile sites shouldn’t use floating headers or footers. And they shouldn’t hijack interface modes. And they should pick sizes that don’t feel like a straitjacket or make it seem like you’re peering at it through blinds. And they should be accessible and standards compliant.
But I wasn’t comparing to the three or four mobile-optimized sites that satisfy all that. I was referring to the more typical millions that don’t.
And yes, given how bad they are, I’d much rather have suboptimal design that I can recover from with a pinch or a double tap than one I can’t.
What would you cite as an example of a mobile site that is more usable than this one?
> What would you cite as an example of a mobile site that is more usable than this one?
This one being the Italian one from the submission or the Hacker News itself? I'm assuming the Italian one. Off the top of my head, sites with good mobile version and similar structure (lots of text and links) are Wikipedia and The Guardian. One tiny nitpick are tables with multiple columns in Wikipedia articles. This is a common struggle and I haven't found an elegant way of showing data-dense tables on mobile screens.
But other than that, all the elements on both of these sites are big enough, I don't have to zoom in, I don't have to scroll sideways, there are no floating elements, and they have distinctive style. They even work well with a dark mode add-on on Mobile Firefox.
Yes, Wikipedia is one of the better ones! But even so, I still find myself switching to the desktop version whenever I need to link a specific section, or get more of the text in view, or view the article in a different language, or not lose my section when come to a page via the back button.
I checked out Guardian.co.uk (assuming that's what you meant), and yes, it is a pretty well designed site that works great on and doesn't seem to even distinguish mobile vs desktop users. But still, this is about the only mobile site I couldn't find anything wrong with. This isn't the typical 99% site.
I find HN to be one of the best mobile websites. It's fast and text isn't massively oversized. You can actually fit information on screen. Many mobile websites I've seen are horrible to use, because they have very poor information density and the sites seem to be designed for 4" or smaller screens.
Most mobile browsers support it out of the box. If the site designer set "user-scalable=no" in the meta viewport property, than that will prevent zooming. It's an accessibility issue and should be avoided.
You say that as if it’s weird to call an iPad a mobile device. Would you say that a tablet is not a mobile device? What do you define as mobile device, and what devices would you use to determine if a web site is “mobile friendly”?
The common definition of mobile device is phone or tablet. The common definition of laptop is computer. These despite the fact that phones and tablets are computers and despite the fact that laptops and even desktops can be moved. It’s pretty easy to find lots of examples of the common definitions. Here’s a good one: https://en.wikipedia.org/wiki/Mobile_device
The question of whether definitions matter when one sub-category or subset is a minority or majority... I’m not sure how to answer that. Why would a definition stop mattering just because something different is a small subset? I must assume that a categorical term includes everything in the category. If you don’t mean everything in the category, then don’t use the term that refers to the category. If you mean phone, then say phone. ?? Right? I’m confused why you would argue anything else.
I am sorry, you’re totally right, is it pretty unreasonably nit picky to differentiate between 10 inch screens and 3 inch screens when it comes to web UX. Smart phones do count as all mobile devices and the only thing that matters when determining if a site is mobile friendly. And of course it’s usually a good idea to broaden the argument categorically to something larger than your personal experience to make the stronger point that most people would agree with you and the other person is obviously up in the night.
Back when Netscape 0.9 was new I had daily arguments with some of the "web designers" who insisted on using HTML targeting browser bugs and other invalid HTML tricks to optimize the aesthetics of their sites.
All you needed to do then, and today, is make sure your HTML is valid and that you don't break things on purpose ("this site optimized for MSIE1.0" type of stuff) and your site will forever be mobile and any-other-html-rendering device friendly.
