Desktop HTML on mobile

[MMWBAdmin]

Was wondering wether less use could be made of  wvr-hide-phone and s-hide (display:none)?

My site https://www.mmwb.nl is hosted on LSWS and uses LSCWP. As I use UCSS, pages/posts get cached for both mobile and all other devices. PHP 8 and WP, WVRX, LSCWP all latest versions (as other plugins as well). Using child theme.

My frontpage (PwP) contains the following HTML:

[wvrx_show_if device=phone]

[show_posts filter=homepage]

[/wvrx_show_if]

[wvrx_hide_if device=phone]

[show_slider name="homepslider"]

[/wvrx_hide_if]

Primary & Secondary sidebars are not shown on smartphone + tablet. I have several (adjusted) widgets at the bottom of the site on mobile e.g.

[wvrx_show_if device=phone]
[search class=mmwb_mob_search max_width=100 size=40]
[/wvrx_show_if]

I used Chrome DevTools to inspect the DOM of the front page, both desktop & phone (refreshed)

On mobile – in my case  – the site-title, site-tagline, header-image, header-html, wvrx-menu-html, header-widget-area, infobar, primary-widget-area and and secondary-widget-area are suppressed by class=s-hide. Together with a menu containing about 200 (sub)items the DOM is over 1300 elements. Even on mobile the header image gets downloaded and the post slider (for desktop) is in the DOM. (But perhaps I’m doing something wrong & I understand it’s hard to know before hand what device/screensize is requesting the page.)

 

[scrambler]

Re you saying that the few pieces that are using display none are significantly slowing your site?

Given the size of everything else, I am not sure how that would be.

I guess it would not hurt for the content to be removed instead of hidden, but how much that is possible or not is for @weaver to comment on

[Weaver]

In the earliest days of supporting mobile devices, the server/host would find out the display dimensions of the client by using a value sent back from the client to the host in a special header transaction. This would give a device name, and there was no standardization of device names. So a server would know the characteristics of the most popular devices – phones, tablets, computers displays, etc. This sort of worked. But in addition to not reliably recognizing different phones, it wasn’t really possible to determine the real display size for a desktop. This really meant designing for 1024×728 displays.

The current model used by most WordPress themes relies on @media statements in the generated CSS to determine the display size, but that is just the design part. The site supplies CSS to display things differently on different sized device displays. Then the device decides which CSS rules to use. This allows for all sorts of different layouts for different sizes. BUT, using just this model, it does mean that all content that might be displayed must be downloaded. There is some control of which images are downloaded based on display size, so only small images are usually downloaded for phones.

There are now some ways to control what content is loaded dynamically, but these techniques are not widely or easily supported by WordPress themes.

I do not think that Weaver Xtreme will ever implement anything other than @media CSS rules for how sites are displayed.

I think it is also technically possible for a browser to determine display size options, and selectively not download hidden content, but I don’t know if any really do that now.

So the answer is that I don’t know of any way to avoid downloading big menus and other content that might not get displayed depending on screen size.

 

[hkp]

@Weaver

Very informative development back story.

@MMWBAdmin

Surely your header images etc. are downloaded to phones because all phones can operate in both the landscape and portrait mode? And your site is designed for that user facility.

It seems reasonable for the phone to download all data for both options at one time – which is a choice the phone makes – rather when called by the user.

On portrait mode, your headers do not appear on the screen, but they do with rest of the items, when needed for the wider landscape screen.

Is this data redundancy not just the reasonable result of users’ instant landscape/portrait interchangeability expectations?

[Author]

Posts