Want to conditionally load CSS for responsive layout

[Dani]

I'm trying to use CSS as so:

<link rel="stylesheet" media="screen and (max-width: 991.98px)" href="/files/mobile_css/daniweb.css" type="text/css">
<link rel="stylesheet" media="screen and (min-width: 992px)" href="/files/css/daniweb.css" type="text/css">

I want to load one CSS file for our mobile layout and a different one for our desktop layout. The problem is the web browser always downloads both files, which completely eliminates the performance advantages of having a more lightweight mobile CSS.

What I'm thinking of doing is using a <link rel> to download all of the CSS that's common between mobile and desktop. Then, conditionally, via javascript, injecting CSS via @import (I guess?) to load the additional CSS that the desktop requires. Pretty obnoxious, no? Is there a better way? And why aren't web browsers smarter here?

[Dani]

So I googled it and came to the conclusion the reason that both files are downloaded, albeit the rules in one of them are completey ignored, is because the browser size can be adjusted after the fact, so the browser needs to know the contents of the file at page load to accomidate window resizing. I tried changing to max-device-width and min-device-width since, surely, the device width can't change willy nilly, but unfortunately it still downloaded both.

[rproffitt]

Regarding the device width change willy nilly. One of my favorite tools is VirtualBox so it is possible for it to change the device width. You can imagine it can really stress out apps and drivers when you do that.

This makes me recall something someone wrote about programming when every case is an edge case.

[Dani]

So I realized after I posted this last night that device width can be changed simply by rotating your tablet (changing the orientation between portrait and landscape) or changing your desktop resolution, neither of which are much of edge cases at all really.

[Dani]

I'll mark this thread solved since it's now understood why this functionality doesn't exist, and I was able to use Javascript to achieve the desired result, such that the CSS common to both desktop and mobile is included in static HTML, and then javascript which checks the resolution is used to dynamically inject the additional CSS that the full desktop experience requires.

[jkon]

Dani I believe is time to reconsider the "adaptive and then responsive" approach. We have talked about it in the past again but what you are planing to do is the same thing client side. Doing it client side has many disadvantages , first of all js events are NOT firing the same way in mobile / tablet and in desktop (this undermines the user experience that I believe is by far the most important thing) , then you have robots not really understanding what you are doing (I wouldn't be supprised if search engines couldn't conclude that such a site is "mobile friendly"). Adaptive and then responsive is easy , you do it server side with a class (I could share with you mine in PHP or in a PHP extension in C++ , but there are many out there) that you can detect if it is mobile / tablet or desktop and serve the apropriate files in View (templates , js , css , images) .

[Dani]

then you have robots not really understanding what you are doing (I wouldn't be supprised if search engines couldn't conclude that such a site is "mobile friendly")

The Javascript only triggers on desktops. As mentioned, the core CSS that is common between desktop and mobile is always loaded. Then, desktop browsers additionally use JS to load CSS that is only used in desktop features. Google seems to perfectly recognize that we are mobile friendly, according to Google Search Console.

Adaptive and then responsive is easy , you do it server side with a class (I could share with you mine in PHP or in a PHP extension in C++ , but there are many out there) that you can detect if it is mobile / tablet or desktop and serve the apropriate files in View (templates , js , css , images) .

The issue with this approach is it tends to be based on useragents. This doesn't take into consideration browser window size, and, more importantly, can be considered cloaking, which is a black hat SEO technique. Google defines cloaking as the web server serving different content depending on the user agent, referrer, etc. For this reason, they have come out and said that they do not want sites to use https://m.example.com etc where mobile experiences are served via a different subdomain, etc. They recommend to always use a responsive layout, which means that the difference between desktop and mobile always be handled clientside. I understand there could be performance issues doing it clientside compared to serverside, but this is Google's strong recommendation.

[jkon]

The issue with this approach is it tends to be based on useragents. This doesn't take into consideration browser window size

That's why I am talking about first adaptive and then responsive (not only adaptive). It is absolutely logical (and needed) in a version e.g. in the desktop version to have several components that look differently based on the screen width (or rarely height). The adaptive part (having two or three versions) doesn't change anything in the responsive part only that it makes it clearer (not extensive media css queries inside media queries) , easier to develop and targeting in what you want in each version.

Google defines cloaking as the web server serving different content depending on the user agent, referrer, etc. For this reason, they have come out and said that they do not want sites to use https://m.example.com etc where mobile experiences are served via a different subdomain, etc.

I am not talking of serving each version in different domains or subdomains and redirect based on the agent. I am talking about serving the same logical content in the same url for all versions but to decide what components will be used server side based on the user agent. These components might be the main template of the site / web app that will be used / CSS / JavaScript and rarely (if not almost never) the view for a specific part. This help you creating web designs that feel native in mobiles without making the desktop version feel like you are in a mobile. Moreover, as I have written many times the JavaScript event fire differently in mobiles and in desktops. The different versions in this context allows clean and fully manageable structures , in my point of view.

They recommend to always use a responsive layout, which means that the difference between desktop and mobile always be handled clientside. I understand there could be performance issues doing it clientside compared to serverside, but this is Google's strong recommendation.

Let's talk a bit about what Google recommends and about cloaking. https://developers.google.com/search/mobile-sites/mobile-seo . As you can read "Google does not favor any particular URL format as long as the page(s) and all page assets are accessible to all Googlebot user-agents" . Of course "Google recommends Responsive Web Design because it's the easiest design pattern to implement and maintain." of course Google doesn't use this approach (only responsive) neither any big webcompany that I know (facebook , twitter e.t.c) all use first adaptive and then responsive. The "easiest" part here takes a lot of conversations , yes it is the easiest to have a result but the hardest to have a result that really works. You can crawl in eshops or forums that use only responsive and find out that in the vast majority some parts don't really work in the mobile version (usually forms), or work in a weird way (usually because they don't take in consideration that in mobile javascript events fire differently) . Moreover if you really want to follow the Google guidelines for a mobile friendly site you will end up with a really messy architecture and css or with a desktop version that look like a mobile web app.

As for cloaking of course I wouldn't use or recommend any approach that Google could consider cloaking (go to dynamic serving (this is more or less same as adaptive approach) and read the cloaking part https://developers.google.com/search/mobile-sites/mobile-seo/dynamic-serving)

If the question is "is it possible to develop an excellent web app / site without any adaptive server side techniche ?" I would answer definitely yes. I haven't seen it yet in real life (only sites that are only responsive and somewhat acceptable in mobile and desktop but not in any way excellent) , but yes theoretically is possible. It would require extremely complicated css and differentiation in the events you use in the JavaScript side.
As I wrote this is only my opinion based on extensive tests and many many real life projects. But of course especially in a field that the technologies change rapidly opinions can (and should sometimes) change also. Maybe in the future I will have different opinions in this one (who knows).

[Dani]

As you can read "Google does not favor any particular URL format as long as the page(s) and all page assets are accessible to all Googlebot user-agents"

You said it yourself. Google considers it cloaking if all page assets are not accessible to all Googlebot useragents. Javascript files are page assets. If you're using useragent to decide which javascript assets to send to the client, then that's cloaking.

[jkon]

Of course Google doesn't consider cloaking if you load different JS files in different versions of your app based on adaptive - dynamic serving (and then responsive view on each one of them) , that each file should be accessible in any user agent is not the same with that you should serve all of these in each html / js . Cloaking is well defined by Google , see at https://developers.google.com/search/mobile-sites/mobile-seo/dynamic-serving at the third part of >Correctly detecting user-agents . The phrase "Google does not favor any particular URL format as long as the page(s) and all page assets are accessible to all Googlebot user-agents." means in my reading what it says , we are not talking about URL formats and this doesn't talk about cloaking.

Before we embrace totally the "first adaptive and then responsive" approach we did various tests with all the different approaches. When I write with such clarity , I know what I am talking about and I am just sharing with you this knowledge that I got through several projects and time. I believe that 90% percent of Google rules and recommendations are logical and the right way to go. Even in the 10% that my theory disagrees it doesn't seem that Google has any penalty for those and in some cases I even agree on those after some years (in one case of those the Google recommendations changed to what I thought logical too) . DaniWeb desktop version is mobile like and DaniWeb mobile version has more problems even than those Google detects. You can make tests for yourself , not in DaniWeb if you don't like , but try alternatives as clearly what you are doing right now doesn't work .

[Dani]

Of course Google doesn't consider cloaking if you load different JS files in different versions of your app based on adaptive - dynamic serving

Yes they do!! Or, at least, that's my interpretation of what Google has been saying over the years. When they say that all page assets must be accessible to all Googlebot user-agents, I interpret that to mean that Gooble mobile useragent needs to be able to download both desktop-targeted and mobile-targeted CSS/JS files, and Google desktop useragent needs to be able to download both desktop-targeted and mobile-targeted CSS/JS files.

DaniWeb desktop version is mobile like and DaniWeb mobile version has more problems even than those Google detects. You can make tests for yourself , not in DaniWeb if you don't like , but try alternatives as clearly what you are doing right now doesn't work .

Why is what I'm doing right now not working?

[jkon]

There is no need to continue this , you don't know anything about web development , and how google see those , you don't have made any tests but you have strong opinions , (please make tests about different ideas before being so arrogant) and those opinions are not contrary only to Google are contrary to logic as well (first what is logical and than what Google likes)... https://developers.google.com/speed/pagespeed/insights/?url=https%3A%2F%2Fwww.daniweb.com%2Fprogramming%2Fweb-development%2Fthreads%2F521414%2Fwant-to-conditionally-load-css-for-responsive-layout this is just a glimpse for why you are failing , you are failing in a lot more sectors that is no the topic to discuss. ( how I have learned : I tried what I disagreed with, and most parts I were correct but in few ones I gained from trying)

[Dani]

I did some research and you’re right. It’s not considered cloaking as long as you aren’t checking whether the useragent is a bot or not.

However, you do need to add the Vary: User-Agent HTTP header or risk VPNs, proxy servers, and other caching mechanisms caching and serving the wrong version to end-users without taking into consideration their user agent.

https://developers.google.com/search/mobile-sites/mobile-seo/dynamic-serving

[jkon]

The "Vary" is not the only thing there are many things that has to be done right , if you are willing to give it a try I would be more than happy to give you more reccomendantions in this.

[Dani]

Sorry for taking so long to see this and respond to it.

You say I don't know anything about web development. Aside from not detecting the user-agent and serving content based on it, what else do you think I'm doing wrong?

[jkon]

Dani obviously the "don't know anything about web development" was an exaggeration. I hear (and read) sometimes false , stupid or even dangerous things about web development or programming that are not based in any facts , the few times I have asked the person with the so strong (false) opinion if have tried out that by themselves I often get variations of the answer (No but everyone says so , I have read it from X that I trust). That is why I consider important in these forums not to replicate false opinions , especially by a member (founder) of your status. In this situation you tried it (or read the doc better) and you realized what is actually true , and I apologize for using that phrase.

[Dani]

Thank you so much for apologizing! I really appreciate it.

In my situation, the JavaScript route was a better option because it only loads the additional CSS required to design the desktop-only code editor upon triggering an open event of the code editor via JS. This saves kB for both desktop and mobile users who are just forum lurkers.