My name is John Ferris. I'm the lead front-end developer at Atten Design Group, based out of Denver, Colorado, in the States. Atten is a design, development, and strategy shop helping organizations like these create positive change throughout the world. Today I want to talk to you about problems. I'll save you all from having to raise your hands and I'm just going to assume that most of you in here are either a designer, a developer, or an engineer. And you chose that path because deep down you like solving problems. If you see something in this world that's broken and you want to fix it, you want to make it better. And we end up having to solve a lot of the same problems over and over. And we end up using common solutions to those problems which you end up with are design patterns. Design patterns are just common solutions to reoccurring problems within a given context. So to give you an example of that, one of the reoccurring problems I deal with on a day-to-day basis, usually multiple times a day, I imagine you guys do too. Probably dealing with it right now is that I get hungry.   So stuff like this can happen. And one of the common solutions that I use quite often to solve the hungry problem is tacos. Tacos are incredibly flexible, very reusable. You can make them in different ways. You just need, you know, flour or corn tortilla. You can use beef or chicken, ground beef, shredded beef, dried beef, fish, shrimp, all kinds of different things. You can create the taco pattern with all kinds of different iterations. You can even make it with ice cream. But tacos aren't always going to solve your hungry problem. Context is important. So for one, you have to like tacos. If you don't like tacos, then tacos probably aren't going to be the right solution for you. You have to be able to get them. My wife and I lived in Australia last year, and it was really hard to find Mexican food in Australia. So we ended up solving our hungry problem with the curry pattern or the meat pie pattern. We had to use different solutions to fix the problem at the time. But today we're going to talk about layouts. And just so we're all on the same page of what a layout is, layouts kind of create the structure of your page. So these are the containers on your page that you would put like your design components. Later on, I think today, John Albin is going to be talking about design components. What he's talking about in that session, that's the stuff that goes into your layout. So layouts hold the content. These components within your layout can have layouts themselves, so it's all recursive. It's all controlled or it's dictated by the HTML. So the order in which your HTML is written and what's nested and what's next to each other, that all affects layout and it's important. And then you kind of control that layout with the subset of CSS properties. So you have like your flow properties, like display and flex and float. You have your positioning properties. So top right, left bottom. And then you have your box sizing properties to actually size your containers. So the properties that affect that, like padding and margin and width. So this is an example of a site with a fairly complex layout. This is a site we did earlier this year for Colorado Public Radio. And there's a lot of layout problems to solve here. If we look at it without those properties we just talked about, we end up with this. And we have some background colors and font sizes and font colors, but it looks like a jumbled mess. The layout's important. So how do we get from this back to this? It can be overwhelming to look at an entire site like this and figure out how you're going to rearrange things and structure things. So it's helpful to kind of break it down. We have kind of this basic problem on this page. We have main content on the left and another column or sidebar, whatever you want to call it, on the right. And it's a pretty simple problem to solve, much easier than the rest of it. But if we look at other details in the site, that same two-column pattern shows up over and over. So we have the main menu at the top is a left column to the social menu on the right. A featured area split into two columns with thumbnails on the right and the main featured article on the left. And we have other featured news items at the bottom. And like I said earlier, they're recursive. So even inside the left column, inside the left column or inside the right column, you have those thumbnails there, again, broken out to two columns. So if we can come up with a common solution to solve this two-column column problem, then it'll work throughout and we save ourselves a lot of work and we can basically create this layout very efficiently. So let's look at some actual patterns. So I want to start off real simple. As first pattern I call constrained element. Give an element a defined width to prevent it from expanding too wide. It doesn't get much simpler than that. So let's look at an example. We have this really wide column of text. The measure here is a little too wide to make it readable. And if we want to kind of constrain that, we just put a width on it and shrink it down. Now it's a little bit more legible. So that's simple, but we can take that one pattern, apply it to a class, and just call it L-dash-constrained. That's just one of the naming conventions we use. And all this has is, you know, at a certain break point, it's got a width set on it or it just has a max width. And we could take that one class and apply it to all these rows of content to make sure that everything is aligned and doesn't bleed out until the actual edge. So that's simple. Use it all over the place. The next one that's related to that is rows of relevant content. So divide the screen into rows of relevant content such that the hierarchy and content relationships are preserved across different screen sizes. So looking at that same site, we have on the left here, we have these rows of content that are all related to each other. We don't have a long sidebar running down the side. And that's helpful when we get down to this mobile layout that everything that's related on the large screen is still related. The proximity is preserved and it all still makes sense. So another example of that is one of the sub-sites for that Colorado public radio site we just looked at. Here we had an issue where the actual desktop design called for this kind of continuous sidebar down the side. But at the top of that sidebar we have ads and ads are really important to this site because that's where they get a lot of their revenue to actually run the radio station. And nobody buying ads wants to buy an ad that's shoved down to the bottom. So when we were designing this for tablets or a mobile view we needed to make sure that that ad was still relatively close to the top. So what we ended up doing is breaking that sidebar up into essentially two sidebars and that way when it reflowed for tablet and mobile layouts we could kind of keep that ad up towards the top. So now I want to talk about the layout modifiers pattern. To follow a naming convention for classes intended to modify layout. So here's an example of just some markup where you have one container and three kind of sections within it and call those primary, secondary, and tertiary. I try to name these with a sort of a vague, reusable class so that no matter what modifier class we give it, the one at the top, like L-dash modifier those subclasses of primary, secondary, and tertiary will still make sense. And I want to point out that we're using the two dashes the sort of smack style. The two dashes for the modifier class and the one dash for that subcomponent we treat these sub elements of the layout as if they were subcomponents. So it's just what the markup would look like and then we can add a class so L-dash3-column so a three column layout. The actual CSS below this is just shorthand. I'm using, in this instance, it's SUSE so a grid framework that we'll talk a little bit more about later. We're just saying basically for each of those columns assuming that's a 12 column grid make them each four columns wide and place them at even intervals across. So sidebars after just adjust a little bit so we have the sidebars coming after the main content area. Sidebars before just flip those and then triptych where we have the sidebars running down the side. So all these are using the same HTML structure for the layout itself but just by switching out that one class we can apply a different CSS to actually create these different layouts which is really handy when you're actually developing. Component layouts this is the exact same thing just with a slightly different naming convention often find that when you're creating layouts for specific components like a node teaser or something like that that the actual layout within it can be very specific to that component and it doesn't really make it very reusable so I just use a slightly modified naming convention for those. I do want to point out the direct child selector that I guess would be a greater than or carrot symbol. Now that's specifying that only apply this style to like the article figure if it's a direct descendant of article teaser. This is less important on the component layouts but if we go back to say where we have primary secondary tertiary we're using these kind of vague naming conventions that we can actually do that recursive nesting of layouts inside layouts and because we're using this direct descendant selector those styles aren't going to bleed into say you have a primary class further down. So that's very helpful. Browser support on it is really good so you can definitely use it. Next pattern is called gutter pull so position an item by pulling it into the gutter established by its parent container. So this is just an example of maybe an article with a block quote in it and we want to pull that block quote off to the side to kind of highlight it a little bit. So we take that quote we float it left and give it a defined width and that allows that text to wrap around and then using the gutter pull pattern we just apply negative margin or negative left margin to that quote and that'll pull it into the gutter and the rest of the content will follow it. So that can be helpful in certain cases. Another example of where that's helpful is say we have a book listing and our markup looks similar to what we were just looking at. We have this book teaser container or layout and the book cover, book title, authors and summary and all those are kind of running together they're all siblings of each other what we want to do is have that book cover pulled off to the side and let everything wrap around it. So on the container we have some left padding to kind of create this gutter and then we take the book cover and we float it left and then add that negative margin to pull it into the gutter. So now we have this two column layout that we were looking at earlier nice thing about this is we don't have to wrap extra dibs around stuff if we resize this we can keep that left column fixed if we don't want to resize the image and all this text will keep flowing straight down and kind of preserve that grid structure that's not going to wrap around the book cover if the text gets long so it's very helpful. Margin overflow is another way we can exploit the kind of negative margin properties so allow an element to overflow its container by applying negative margins to both the left and right sides. So here's an example of a common block we have a block title and some block content so you've probably seen this mark up a lot if you do a lot of Drupal work and then applying negative margins to either side of the title we can actually have that title expand out beyond the edges of that container so that works for creating some fancy block titles another place that that pattern can be applied is say we have three columns and each one of those is just defined by setting the width to 33.33% floating them left and then adding padding to each one so it's very simple to create this three column layout but there's a problem there in that the actual edges of the text aren't lining up with our grid like these are pushed in so using the margin overflow we'll just set a negative margin or whatever the padding size is to kind of expand that container out beyond its parent and that lines everything up so there's other ways to tackle this using like nth child or whatever so it kind of depends on the context that you would use it if you have to support older browsers that don't support like the nth child selector you'll need to do something like this to get things to line up this one's kind of fun in terms of ratios when the aspect ratio of an element is known but the target size is not you use padding in absolute positioning to preserve the aspect ratio of an element so a good example of this is like a YouTube video which are normally added to a page with an iframe and I'm sure if anyone has done responsive sites where you have video or embedded media like that these can be painful so you can't do the max width 100% like you can with an image the browser doesn't know what the aspect ratio of an iframe is like it does with an image so what you have to do is actually oh, here's an example of it going wrong this is just using the max width so in order to fix this we take the parent container and we add top padding to it which is the ratio like the actual aspect ratio of the YouTube video or whatever that we're embedding and this is due to the fact that when you define top and bottom padding as a percentage it's actually a percentage of the width of the element not a percentage of the height so we're essentially creating this padding area along the top that is the aspect ratio of the video that we want so we just take the video itself we absolute position that at the top and then give it a height and width of 100% and then if our container expands or contracts then so does our video so there's libraries out there like FitVids that handles this for you it's pretty much the CSS that it uses I think the only advantage to using that is it'll actually calculate what that aspect ratio is if you don't happen to know it ahead of time like I know that all the YouTube videos that we're embedding on a site are going to be the same ratio so I don't necessarily need to use that library but if you're using Vimeo and you have just varied width things you might need to look at FitVids so now I want to talk about grids and the overall grid system pattern is divide the screen into a series of vertical columns to facilitate the organization and alignment of components so just give an example of this is a grid overlaying the Indianapolis Museum of Art Sites you just see that we're aligning all this content along the grid to keep things kind of ordered and clean I'm not going to get into why you should use grids I think they're a good idea there's great books out there that go way more in-depth about the value of grids and how to design them Ordering Disorder by Coy Van and Designing for the Web and Mark Bolton I highly recommend both of those but I want to talk about the actual patterns that you would use to implement grids on a site so you have a guttered grid so for each grid unit and grid system include a gutter to help space content if you dealt with grids before like 960 grid you've seen this a lot this is how we do a lot of grids so this is just a simple 12 column 12 column grid on Drupal.org so we have these columns and they're set gutters in between that help space the content so another option you have is a gutterless grid and this is how we've been designing sites for the last 8 months or so so you exclude gutters from the grid unit instead use empty columns as the gutters themselves so with this Colorado Public Radio site we just got rid of the grids altogether and did 24 columns and we actually use some of the columns themselves as the gutter I find this is a front end developer much easier to work with because you're not having to deal with some of those nested padding issues that you often get with a grid system and gutters in this particular case we used a 24 column grid now we often use a 23 column grid and that actually works out for using columns for the gutters if you have a 23 column grid and you want to do a two column layout you can have 11 columns on one side 11 columns on the other side and then one column down the middle it works for 3 columns 4 columns they could even work for 5 columns but as a front end developer much easier to work with and our designers are enjoying it as well so symmetric grid constructed grid from equal width grid units again the same thing what we're showing here is that each of these columns are the exact same width all the way across back to that Drupal.org example it's made of 12 equal columns so another option we have is the asymmetric grid so construct a grid from varied width grid units designed for the content so this is where we're actually designing a specific grid layout based on the actual content of your site so this is an example from a blog post that Mark Bolton did of like an e-commerce site that's selling t-shirts and the grid is constructed around this photo of the t-shirt and the actual information going down the side the colors on the edge so this grid is very specific to the content the math involved with doing this kind of made these to say impossible but a little too tedious to implement in the past but now with preprocessors like SAS unless this is far more doable and actually pretty easy I think it's just a matter of when you're actually designing the site at the beginning that's a decision you have to make at that point and kind of adopt a grid then as opposed to just starting off with a 23 column grid or a 16 or 12 column grid so one way to implement a grid system is with the class based grid system so align elements to the grid by applying a system of predefined classes to markup so a lot of you will probably recognize this this is the foundation grid framework and this grid framework is created by actually having these sets of predefined classes like large two or large three columns, large nine columns those all have CSS properties applied to them and you actually work with this and develop this grid by applying these classes to your markup this is really good for prototyping things quickly it's good in situations where you have like complete or a lot of control over the markup especially in your layouts which isn't always the case in Drupal it's getting better but sometimes there are things that are just hard to actually apply this class to that you need to make this grid system work so here's an example what that markup might look like one of the earlier problems with this approach and responsive design is you would give something a class like I think bootstrap used to use like span eight and that when you when that class is applied at different screen sizes you know you might not always want that to be eight columns you know at a smaller screen size you might want it to be a full twelve columns so there were some issues with like the semantic nature of that of like you know I declared this to be eight columns but I don't want any columns here so the way that a lot of grid systems are addressing that now is by using these prefixes for like small to large four so in this case small two means this should be two columns on a mobile layout and four columns on a larger screen another approach to that is the semantic grid system so align elements to the grid by applying layout properties to selectors using a grid framework so here we're not actually we don't have a set of pre-defined classes that we're using we're able to apply the CSS and all the math involved with it using grid framework in a preprocessor so these three examples here are all the exact same the same layouts defined in three different grid frameworks or SAS based grid frameworks are Singularity Suzy and Zengrids now all these pretty much do the exact same thing as far as the final output just the syntax is a little bit different in the actual underlying math and obviously the underlying features that come with the grid system are different so essentially these are just saying for the primary elements make it eight columns wide starting at the first column for the secondary element make it four columns wide starting at the ninth column of a 12 column grid so behind the scenes like how those are actually implemented in CSS one common way is using float layout pattern so create columns by floating a series of elements with defined widths so we already saw this earlier we have primary secondary tertiary containers and we want to create say three columns with that we just give each of those 33% width and then we float them left and we have three columns so a lot of grid frameworks were implemented this way this works really well if you don't know how many elements that you're going to have so say you have a view showing like profile teasers of all your staff members and you don't know if there's going to be nine or 11 or 24 staff members by using this type of layout you can apply that and they'll just kind of flow around into multiple rows of content works really well in those situations adding padding to each of those here we're using box sizing border box which if we add padding to the element it's not going to affect the overall width of it so we can add padding and it's not going to change the fact that it's 33% wide by default browsers use border box content box and that would actually if we added padding to something that would actually make the box larger and it would cause that last one to wrap around so here we're doing the same thing we just changed the width to 50% to create two columns so an alternative to that is isolation layout so given a series of floated elements give each a negative trailing margin in order to reset the orientation of the following element I think this is much better much easier to describe with an example so here we have that exact same layout everything's lined up three columns across and using the isolation method we'll actually give a negative right margin of 33% to all these elements and what that does is it kind of collapse the space that that occupied and sort of overlays everything and what you get is kind of a set orientation on your elements so that you can then with left margin be able to position those across the row anywhere you want this is really good for if you have a complex grid system that you can position these things isolating them from their surrounding elements so it gives you a lot of flexibility in where these items are placed you can change the order of things it works for if you're implementing a site with the right to left language and you can by messing with or playing with the settings for clearing you can actually have say we have this primary container we have secondary container that's taking up the right hand column and it can flow down as far as it wants because it's floated right and then third container tertiary is only clearing left so it clears that first item but it doesn't clear the second one can get as long as it needs and the third one will just kind of bump up underneath it as soon as we clear right with an element that's going to clear the secondary column so if you're looking at grid systems it's good to have one that actually allows you to control the direction of which way you're floating because it gives you this flexibility this is how we did that earlier example with ad on the colorado public radio site being able to take that column down the sidebar and still have the other content that comes after the ads float up underneath it so I'll talk a little bit about how you apply these to Drupal none of what we've talked about so far is Drupal specific, it's all CSS so as long as you can apply CSS to the right places in Drupal then you're golden and can use it but where do you do that a lot of times we do this in template files so we usually have a page template file is a good example because that's where all your main content regions are on the site so applying these classes directly to page templates and creating alternative page templates for different layouts that works really well as these things are recursive if you have to do layout on an individual node adding these classes directly to node templates works really well and then on the user side user profiles when you do this you can often end up with a lot of template files so one great way to share these common layouts across different template files is using theme hook suggestions so in Drupal 7 you have to do this in pre-process so you just tell Drupal sorry, I'm going to back up a little bit so this is an example of say if you need to override the front page template in Drupal you do that with page in front if you want to override the article content type in Drupal you want to override that node template use node-article those are theme hook suggestions that are already built into Drupal you can add as many theme hook suggestions as you want and you do that through pre-process so these are just little snippets, this is in a full example but we would have this variables array that we pre-processed for the node or page template and we can based on whatever logic whatever PHP logic we have on the server side with the page you can do it based on the path of your page if someone is logged in or not with the node you can do it based on view mode or content type these theme hook suggestions so it would be like page underscore underscore sidebars after is a good example one that we use a lot or node underscore underscore teaser if you are doing like a component layout and then this is just a way to allow a lot of different content on the site reuse those same templates and it keeps your templates nice and maintainable another great way for creating layouts is using C tools layouts there is a few modules and a couple of themes out there that actually use C tools layouts panels and display suites both use C tools layouts omega 4x I believe I haven't actually used it but I believe it uses C tools layouts and a C tools layout what it allows you to do is actually define a layout for your site with specific regions and a specific CSS file for it and a specific markup so if you have if you are creating regions the normal way in Drupal you do it by adding them to your .info file and your theme and basically that means that you have this one super set of regions that no matter what page you are on or what layout you are using those are the regions you have available to you C tools layouts allow you to define those regions for each specific layout which is really nice you don't end up with all these regions called above content or above below content or sidebar first, last all these weird regions that you need to kind of shim into whatever you are actually creating a layout for so creating your own C tools layouts you need a .info that actually defines those regions for you and what the layout is called and what not you don't necessarily need a thumbnail but you create a thumbnail so that when you are selecting a layout your content administrator is selecting a layout in the Drupal admin UI they can actually get a preview of what that layout is supposed to look like the actual CSS to create the layout and then the actual template file, the markup for your layout here is just an example of the .ink file it has the title, the category that is where it is going to show up in the admin UI the icon is the thumbnail the theme is the you are actually creating a theme hook in Drupal so this is going to be whatever you put the string you put in your theme variable or property key whatever it is for an array that is going to be the base name for your template file so in this case our template file is going to be sidebar-after .tpl that PHP and then an array of the actual regions that you can put content in here is an example of what this layout would look like pretty simple template file, I apologize the syntax highlighting in this thinks that the opening PHP tag is actually a comment so don't copy and paste this into your your file but this is just simple template file it is addressing the actual markup of our layout and then the actual CSS so in this case usually our layouts are going to be more much more complex than this but this gives you an idea so this CSS is actually going to be loaded dynamically on any page that is using this layout you can also define the admin CSS which is the CSS that is going to be used when this layout is previewed say in the panels UI so you can load separate maybe a smaller CSS file that doesn't collide with like your 7 admin theme or whatever you can load separate CSS files into the admin UI so I want to talk a little bit more about design patterns and where you can actually find them some examples of them so uipatterns.com is a great example of actually defining patterns this pattern this pattern library is actually pretty dated right now which is unfortunate because it is really good about actually giving good concrete examples giving reasons why you would actually use a pattern and the actual context that it applies to so if you are just looking for general information about design patterns this is a good place to go to for examples Luke Robluski wrote multi device layout patterns which is just a quick rundown of some general solutions for creating layouts for responsive sites Brad Frost has responsive navigation patterns these are patterns that are specific to the actual problem of how you do like mini structures or nested mini structures complex menus on mobile devices so that is definitely good he also has just a general I think it is called thisisresponsive.com which is just general patterns for responsive design and where a lot of people have heard of design patterns in the past was actually a book that came out in the 90s about object oriented programming called design patterns it is also known as the gough book or the gang of four and this is applying design patterns to actual object oriented programming which is pretty interesting to read the actual thing is that this is still very relevant today as you know it was written back in the early 90s but the idea of design patterns did not come from graphic design or web design or computer science it actually came from architecture so an architect named Christopher Alexander back in the 70s while he was a professor at UC Berkeley put forth this theory called the timeless way of building it was all about designing buildings not by their actual form but by the human interactions that they are designed to to facilitate he followed that up with a pattern language which is 253 different architectural patterns that him and his colleagues documented based on observations from like some of the most timeless and beautiful places around the world and these patterns don't just talk about architecture in terms of individual buildings they work on a much larger scale so like how how to design like a whole region and within that like cities and how do you relate cities to other cities and inside of that like neighborhoods recursively just like the layouts we were looking at all the way down to the actual building how do you design the entryway what's the built-in furniture and what are the things that you hang on the wall so it was very vast and these patterns allowed just the layman someone who wasn't necessarily trained in architecture to actually design the buildings that they lived in just by applying these specific patterns to their specific design problem or architectural problem so to give you an example of that pattern number 241 is called seat spots it says choosing good spots for outdoor seats is far more important than building fancy benches indeed if the spot is right the most simple kind of seat is perfect and cool climates choose them to face the sun and be protected from the wind and hot climates put them in the shade open to summer breezes in both cases place them to face activities this brings up an important point that design patterns are not designed they actually wrote this pattern based on going out and doing research and the students went out on the campus and they actually observed all these different park benches around the campus where people were sitting which benches were full of people which one sat empty and then they wrote that down it wasn't necessarily somebody just saying yeah I think I think good seats have cushions and then boom that's our pattern they actually did it by observing things that worked to try something and then the things that worked they actually get documented so design patterns are observed it's very important distinction you can't just go out and design a design pattern so what does that mean for us as developers and designers so start looking for patterns in your own work and you're solving a lot of these problems over and over again like just try to take note of what are the solutions that you're using you know be mindful of field good code and what I mean by field good code is the stuff that you know you're writing it and it just like it clicks you know it's going to work it's tested across different browsers you know which situations it's going to work in it doesn't matter in terms of layout like how long content is going to get the layout still going to be preserved it's not going to break down and then figure out what you need to do to make that repeatable like try to abstract the actual solution from the specific problem that you're addressing to make it work in different contexts and also define like what are those contexts in which this pattern doesn't work like we looked at the you know the float grid pattern and there's places that that doesn't work well the isolation pattern isn't going to work for something where you have a whole bunch of unknowns like how many elements you can't go in and actually say for all 24 elements I want this in the second column or third column so it's all about like finding which solutions work when and then share it with others and that's what I'm doing today so thank you this is just a link to the actual session if you want to mind leaving some comments let me know how it was if you learned anything and we do have time for questions so if anyone has any questions there's a microphone in the middle anyone? no? my favorite pattern depends on the context yeah I mean I think that the gutter pull one of being able to like the example of the book teaser being able to pull one element out of a bunch of elements without having to actually define the layout and all those other elements that one like when I figured that one out and realized that it worked everywhere like it was a good day yes would you mind stepping up to the mic so I was being recorded I'm just starting to work with design patterns to learn and to have a feel for them and I was also questioning myself how come it can be a pattern to be implemented while doing test-driven development starting from a test where you're starting from the solution kind of and you have to figure out which pattern fits the needs for my code are you asking how to choose the pattern? yes, something like that yeah I think it's defining the context of what I guess which pattern it's going to work in which will be the blueprints regarding which the developer could decide on the correct pattern of kind of should be implemented I'm not sure if I have an answer to that sorry I may not actually understand the question could be the problem well, sorry sorry I was wondering it's more of a UX question for people creating content than a layout or design question but when you use C-tools layouts what do you guys use so that content creators can pick a layout do you guys end up using context or panels how do you integrate like layout control with content creation and I know it's not quite the topic of your talk but you guys do this a lot so so, panels we have used DisplaySuite quite a bit in the past and just about all of those cases the particular clients that we were working with didn't want to even mess with that they didn't want to need to get in and actually change that layout but the same admin UI that we were using was available to them panels is something that we've let or we've had clients actually use and panels has a nice interface for actually choosing the layouts I think creating those thumbnails is extremely important I've actually created just a Photoshop template for creating those thumbnails real quick so for each custom layout we do, we create a thumbnail based on the desktop version of the site and I think that's pretty clear if, well it's clear in the context of the panel's interface is clear and easy to use which it isn't do you guys use IPE like the front end editor for panels the inline editor and then let people mess with that or do the content creators go through the panel's back end and then pick a layout and then kind of mock it up somehow the panel's back end so my issues with IPE is that in order for that to work it needs to add additional markup which, in a lot of cases will break the responsive layout your descendants selectors suddenly explode so no we haven't and I think it's a tricky issue because um responsive layouts they're complex I don't think there's any way around that and when you start adding additional markup and CSS to handle like this whizzy wig editor on top of creating layouts I think, yeah that's a tough nut to crack could you give an example of where things might have gone wrong or if you've realized midway through a project that perhaps you would like to have implemented things differently would you go back and kind of reimplement those things or do you just kind of put that to one side and say right we'll do it better next time yeah so naming things is always hard that primary secondary tertiary naming convention is something that came out of a lot of pains of naming something like sidebar and then all of a sudden we want to change the layout and it's no longer a sidebar so naming things is often something that I'll have to go back and refactor and I've found the more general you can make something the better, you know if you're styling layouts based on like a class that's say node article teaser like it's a layout specific for the article teaser and then you have this other content type called news or whatever you want to call it and you realize that oh I can use this exact same layout for this but then you name it you add that article teaser class to it and then all of a sudden like the semantics of that class name have gotten jumbled because you're naming things based on a Drupal implementation rather than the actual design semantics of it is that good, you want more examples of when things have gone bad no that's good I suppose would you say it's to do with documentation and kind of trying to set standards for yourselves internally that you're carrying through to the next project yes so documentation is something often times we'll start off documenting things well and then as you get down to like crunch time and actually implementing a project on budget that that becomes a very much like it's a lower client priority than getting the site launched and done so then it kind of comes down to you know does your does your client want to actually pay for the time to go back and document you know it's a business decision yeah thank you you mentioned architects who had written a book of good patterns and it seems like a really useful thing for architects is there any kind of similar resource a book or a site that does the same thing for patterns that can be used in sites in Drupal not that I know of yeah definitely nothing specific to Drupal something at all I mean the ones that I listed for like Brad Frost and Luke Robluski are good in terms of just like responsive stuff are there are there specific types of problems that you'd be looking to solve or just in general like there isn't we should start one all right thank you over oh sorry yes is the presentation online yep this is on my get up page I will add a link to the actual session page on the Drupal con sites so go to that link find the slides and give me some feedback thank you


My name is Josh Rosenau. I work at the National Center for Science Education, and I'm a biologist and now something of a specialist in why people reject science. I've been at NCSE seven years in change, and before that I was a grad student at the University of Kansas and got involved in the fights over teaching evolution there and decided that I liked that part of what I was doing better than what I was supposed to be doing as a grad student, which was a valuable lesson to have learned, and possession opened up at NCSE, and off I went to do it and actually make money at it. So what is the purpose or the goals of NCSE? NCSE is a non-profit that defends evolution and climate change in school and more broadly makes sure that science is taught as science in classrooms. In the United States, our education system is very much localized, and individual teachers have a fair bit of autonomy. The individual school districts, the 17,000 school districts across the country have a lot of independence to set curriculum, to choose textbooks, and to hire and dismiss teachers who don't happen to match the community's desires. So there's a lot of informal pressure that can come to bear on individual teachers to ask them to just stop talking about evolution so much, not get into climate change, it's making parents uncomfortable, or to have them teach both sides, to teach non-science alongside science, or to teach things that have been debunked long ago alongside what is known to be the best available science today. And we also see things at the state level, efforts to change the science standards that try to guide the districts in a particular direction, that guide what textbooks are chosen, or state legislatures trying to rewrite the laws about what standards can be adopted, what must be taught, what may be taught to open the doors for teachers to go off the script, to go beyond what has been approved. Science denial often will cherry-pick a scientist or a sentence from something that a scientist wrote and say, here's a scientist who says that climate change is not happening. Here's a scientist, and sure, there are other scientists out there who say it is happening, but there are two equal and opposite experts, so there's a debate. Let's just have the debate. Make it seem as if they're just these two equal sides. Attacking the science in various ways, we talk about the three pillars of science denial. The idea that you attack the science, you make it seem as if the science evolution, climate change, vaccines, whatever it might be, is not credible, not widely accepted, that scientists are all turning against it and any day now the whole thing is going to collapse. Perhaps it's only being propped up by some conspiracy of scientists who are working behind the scenes to exclude contrary voices. All of this that I'm sure you have and will talk to lots of people about already. And then a pivot to the consequences. In the case of evolution, to say if evolution were true, it would mean that it would have bad consequences for society or if it were true, it would be bad for you individually. You would not go to heaven or people would behave bad. If we teach children that they come from animals, they will behave like animals. Really common argument. So it's essentially, regardless of the truth, it's morally bad. We shouldn't teach it because the consequences, regardless of whether it's true or not, would be harmful. But it can't be true because it would be bad if it were true. And then to make this fairness argument that there are two sides, usually exactly two sides, regardless of anything else, and we should just present both equally. We should present creationism as understood by fundamentalist Christians and evolution as understood by scientists and give them equal weight. But we're not going to bring in Native American creation stories. We're not going to bring in, you know, it's not that sort of two sides or many sides. Anything that weakens the science in that case is seen as inherently supporting the other because there are these exactly two possibilities. And I don't know is not one of them and there's not a third path. There's not multiple paths within the science. It's essentially either the science as it's understood or the pseudoscience. Creationism, they have this mantra, teach the controversy and climate denies it desperately trying to get into public debates with scientists. And have very much adopted that rhetoric of, you know, that there is a controversy and look, we're talking about it. So there must be a controversy, so we should teach the controversy. In science classrooms, regardless of whether there's scientific validity to it. So is it a good or a bad idea to get into public debates with science deniers? I don't think debates are productive. Science is not settled by a stage debate. Debate in many ways is a sport. You know, someone who's a high school debater will be given a topic and before the competition, but when they show up there's a coin flip of which side, which team is going to take which side of the topic. The skill of a good debater is to be able to argue any position, regardless of the truth or validity. Science, scientific questions are resolved in the literature. They're resolved with experimentation and peer review and all of that, which takes longer than an hour long stage debate and doesn't necessarily mean that everyone gets equal time and equal weight. So participating in debates where you have that structure, it just reinforces that idea that there are exactly two possibilities and that anything that weakens one must strengthen the other. So it doesn't teach people how science works properly and it gives equal time to ideas that are wrong. There are other structures. If people want to have those conversations, there can be ways to do that and to explore there is a social debate. There is something going on debating what we should do about climate change. Sure, that's a policy decision. We debate policy all the time. How should Christians think about evolution? That's a debate. There's an active ongoing debate. How much will sea levels rise? There's an ongoing scientific debate on this topic. Some people say this much, some people say this much. There's research. We can explore it. But none of those, the error bounds on neither of the two, none of the positions that are out there in the science, the error bounds don't include zero, right? So a debate between will ocean levels rise or not has no place. But will it rise a meter or will it rise 10 meters? Will the West Antarctic ice shelves slide off and inundate coastlines? Some people say yes soon. Some people say we've got a while. That's legitimate debate. So shifting from something that's not a scientific debate to something that is legitimate, shifting to a policy debate that's alive and active debate, sure, should we do anything about climate change? That's not a scientific question. It's informed by the science, but it's informed by values and other things that people can certainly debate productively. I think probably the most obvious parallel is the love of lists of scientists. So the Oregon Institute's list of 30-some-odd thousand people who claim, at least, to have scientific credentials, saying that climate change isn't real. Creationists love to create lists like that. Here are 600 PhDs who say that evolution is wrong. And we responded to that a few years ago with something that we call Project Steve, where we said, okay, you've got 600 people who are PhDs in some field who say that evolution is wrong. Here are 600 people named Steve, PhD scientists in relevant fields who say that evolution is the best description of the diversity of life on Earth and that it should be taught in schools. You can create lists of almost anything, and it can sound really impressive, 600 scientists, but we've got 600 Steve's. We've got 1,400 Steve's now. And it makes it really easy then to say when someone says, oh, they're all these scientists, the Heartland Institute just sent out around a mailing, here are 58 people who will debate climate change. How many of them are named Steve? How many of them are scientists? How many of them have credentials? Sure, but how many of them are named Steve? And how many scientists can you find named Steve who think that climate change is real and is caused by humans and, heck, that we should do something about? You think that humor is a useful communication term? Humor is incredibly powerful because there's essentially nothing you can do against it without looking humorless. You either take the joke really seriously or you just laugh at yourself, but there's no denying it at the end of the day.  You either laugh along with the joke and diffuse it to some extent like that, or you just make it that much funnier. Do you have any tips for scientists who are trying to communicate with science for the public? I think asking questions is something that scientists can be bad at and that can be really important. Scientists tend to come at this thinking that there is this knowledge deficit out there, that I am a scientist, I've studied this for a long time, I know a bunch of stuff.  It doesn't work in the classroom, which is unfortunate because that's where scientists tend to do this the most, but it certainly doesn't work with the press. So figuring out where people are coming from and what they are wondering about, what are their questions, what do they already understand and what would they like to understand, what's relevant to their lives. If they're resisting the science, if they feel like there's credibility to science denial claims, why? It's almost never, certainly with evolution. When I'm talking to someone who is really insistent that evolution is wrong, I've had more of these conversations than the same sorts of conversations with climate change but the same dynamic plays out there. They start off saying, well, there are no transitional fossils while there are. There are no archaeopteryx. No, archaeopteryx is a hoax or it's not really the ancestor of modern birds or whatever. So we can sort of go down that rabbit hole for a while and we can be arguing about fossils, but it doesn't change their mind and so at some point I'll try to sort of bring the conversation around to something else or they throw up their hands and say, well, okay, maybe you're right about that but you can't create genetic information. So we talk about genes for a while and eventually it somehow comes around to creating life on Earth and now we're having the real conversation because they've introduced the idea of religion into the conversation and that's what's driving them to deny evolution. That's what makes them care about archaeopteryx or genes or any of these other things. So we could talk about genes and archaeopteryx and fossils and all sorts of cool stuff all day but they're not going to hear what I have to say until I've addressed whatever concerns they might have about I can't think that archaeopteryx is the ancestor of modern birds because if I did then evolution would be right and I would have to throw away everything that I pulled true about the soul being reunited with my loved ones after I'm dead. Which would you rather be right about? Right? So know where people are coming from and think about ways to connect to them on that same level. In that scenario, do you share their religious beliefs or do you know someone who does have a problem with evolution? Do you know someone who shares their political or economic beliefs, their concerns about certainly in the US a lot of the rhetoric around climate changes making sure that America is America that we will not be the same sort of country if we do all the things that are needed in order to address climate change. So talk about the military, talk about businesses that are already taking serious steps on climate change. Connect it to those concerns which lets you get back then to the science. They're doing this because they understand this piece of science and here's where that comes from. So you work back to the science from those same concerns. It works the same regarding vaccines, climate change, evolution, GMOs, nuclear, almost anything where people have absorbed something that is that connects to their values, connects to their identity in key ways that are leaving them not really appreciating the science. You have to start there. The place that I always start is sort of the very simple first principles. We know that when we're burning a lot of fossil fuels and other stuff that releases carbon dioxide into the air. We see this all around this is hard to dispute and we know and have known for 150 years that carbon dioxide does in the atmosphere. We know that it traps heat. So what do we expect to happen? From those two simple facts that are readily demonstrated what do we expect to happen? We should expect to see temperature increase. We should expect to see that change patterns of weather in all sorts of ways around the world and that's what we see. So that's the baseline and we had that worked out Svante Arranius in 1896 had worked that out. Everything else is just icing on the cake. There's a lot to tell us how we should predict weather patterns to change how we should expect all sorts of other things to happen but the basic story we've known for a long time and now it's just a matter of what we do with that information.


Hi, everyone, and welcome to the June 10th edition of the JavaScript SEO Office Hours. I'm super happy to see that a few people joined the recording as well, and that lots of questions were submitted. So let's get going. I'll start with a question from YouTube, and then I'll ask the audience if there's any questions in the audience as well. So is Google Search Console a good way of identifying whether Google is able to crawl links that are coded up within JavaScript? It is if I run a URL that has lots of JavaScript on the page, and the source code, is the source code captured in Google Search Console a good way of identifying how Google is able to crawl that JavaScript? Yes, if you use any of the testing tools, so the URL inspection tool, in Search Console, the rich results test, or the mobile friendly test, or the AMP test, or whatever, you see the rendered HTML. That is what Google sees if something is in there, good. If something is not in there, not good. That means that we are not seeing it. That's relatively easily said and done. Do we have questions from the audience? I've actually got a question that I did submit as well. So it's just around. So it's on a bit of background. We basically have a number of customers that we help to do SEO. And a lot of the websites are built in platforms which don't give you the ability to control changing different elements, really basic elements, like title tags, headings, that sort of stuff. So we built a little JavaScript script that we added onto their website that would give us the ability, using JavaScript, to update some of these elements. Google didn't always seem to pick up the changes that we made. So it's kind of two questions. One was, is there a certain way in which we should load that JavaScript, a certain point at which it should be loaded in when the page is rendered? And then also, secondly, what's the best way to check to see that Google's picked up them changes? So generally, there's no problem with doing that. And I would say the earlier you do load the JavaScript, the better it is. Because we are running a bunch of heuristics to figure out when the page is done. So if it takes a lot longer, then basically, if the page does its thing and then a long time passes and then your script kicks in, we might actually miss that last bit. So the earlier you can do it, the better it is. Even better if you can do it server-side. If you can't, then that's fine as well. And to test this, the best thing is to use any of the testing tools and check in the rendered HTML. If what we are rendering there or what we are seeing there is what you expect us to see. OK. Yeah, because we started doing this quite a while ago, I think, before the new version of Search Console. So that wasn't kind of fully available at the time. And what we were doing was we were seeing within the actual search results page for the website the kind of the title that got brought back and the meta description that got brought back, whether that was the updated. Is that not a good way to test it? That's not really a good way to test it because we might rewrite that. The actual thing that was happening was it was actually showing the non-rendered title tag was showing in the search result and not the rendered. Yeah, that might happen if we think that that's a better choice. OK, that's fair enough. Yeah, that's fine. Then that's my question answered. Thank you. Awesome. You're welcome. Then we have a question on, hold on. Now I actually confused myself and I'm not sure if I am in the right thing. Yes, here. What's the definition of the load event in the DevTools? Mozilla says the load event is fired when the whole page has loaded, including all dependent resources, such as style sheets and images. But what is the definition of the whole page is loaded? So there's two events, technically speaking, that the DevTools highlight. One is the load event. One is the DOM content loaded event, I think. The DOM content loaded event is the moment when the DOM has entirely been parsed, but things might still be pending. So for instance, if the HTML has an image and an iframe and the style sheet and whatnot in there, then the DOM content loaded would fire the moment we have parsed the HTML. So even before we know what's in the iframe, before we know the image, if the image exists, what the image looks like. So that's basically when the HTML has been parsed and understood and the DOM has been constructed. And then the load event waits for everything to finish its thing.  But these scripts in turn might do things themselves, like load something. This might or might not be before the load event fires because the load event fundamentally says everything that is referenced in the DOM has been downloaded and is there. It does not mean that the scripts have been executed and also just imagine a script could hypothetically have a set timeout for five seconds and then after five seconds make a network request. So the load event wouldn't wait for that to happen. The load event would fire the moment everything has been downloaded that belongs to the page. Every style sheet, every image, every video, everything. It's content that is added afterwards by JavaScript is not considered in the load event. So the load event might fire before these things start to load. I know that's a little tricky sometimes to figure out why the load event is in a certain spot not later or earlier, but that's roughly how that works. All right, do we have other questions from the audience before I go to the YouTube questions? Yeah, I have a question about server-side rendering. So I'm considering doing a hybrid approach right now it's client-side rendering and to, let's say, save resources or prioritize. I'm asking what would you recommend for the approach to take on what to prioritize. So for example, content or title tag or canonical, what should I prioritize in terms of going server-side hybrid? I would, if you want the biggest bang for the buck when it comes to server-side rendering because server-side rendering is quite an investment both in coding effort as well as infrastructure. I would say everything that is critical content. So title, meta-description, canonical, and the actual content that the user is interested when they come to the page. So what that is depends a little bit on what your website looks like. If it's a shop, it's very likely that the main content that you want to server-side render is probably the actual product description and product images and stuff like that. If it's a blog, it's very likely the article content and then everything that is kind of secondary, I don't know, like comments, ratings, whatever, these kind of things can potentially be client-side rendered afterwards because you want the largest contentful paint, the big blob of things that the user is interested in. You want that as quickly as possible and as quickly as possible, usually means server-side rendered. Great, thanks. Also, in addition to that, the canonical right now on the server-side, almost on all pages is going to the home page and then the rendered goes to the inner page. So would you then prioritize that over critical content? I would say no. I would always go for the critical content over any of the meta information. But having that, it's probably better not having a canonical than having an incorrect canonical and then updating that or adding that using client-side rendering because it is unlikely, but it can happen that we get confused when you give us a canonical before the rendered version, after the rendered version. It is unlikely. I say that again because I know that there will be tweets and blog posts about this later. It is unlikely that this happens, but it can happen. It's just a matter of giving us misleading or conflicting information might mean that we picked the wrong one. One way that I tried to investigate to see if that's happening is a new page. So about April 2nd is when the site switched over to mobile first index. And after that, a new page was published. And the user declared canonical in the URL election is the desktop URL. And I have a separate mobile site with end dot. And I'm suspecting that the canonical is the cause of this. So instead I would expect to see the end dot as the canonical. With end dot and mobile friendly, sorry, mobile first indexing, there's like lots of variables in the error. It's hard to pin that down, but it could be. I guess what I was trying to say is that is Search Console or can I use Search Console URL inspection as an indicator if there is confusion regarding the canonical? Yeah. Okay. Thanks. You're welcome. All right. We have lots of questions through YouTube today. That's great. Is it a problem to return a robot no index in the HTTP header of JavaScript or CSS files? I know it's better if they're crawlable, but should they be indexable from an SEO point of view? I don't think it hurts. I don't see that much of a use for it because normally they don't get indexed. So I would say you can do it. I wouldn't, unless you are seeing a specific problem in that regard. I would not robots.txt block them. Different thing. I know that that's not in the question, but I'm saying this to make sure that no one gets this wrong. If your robots.txt, sorry, robots block JavaScript and CSS files from crawling, that might lead to problems in certain cases. So I would not do that. One more YouTube question. I use server with pure engine X and red is the CMS's WordPress, okay. Optimization optimizations are server level caching, may find native lazy loads, long form pages. Page speed score is 92. The loading speed components are mostly green with nothing going above 3.2 seconds, but cache your, so don't use cache. The cache colon URL thing is just a convenience feature. If it doesn't look right, that means nothing. Ignore cache. Cache is not a testing tool. It's not a testing tool. Don't use the testing tool. Search console inspect URL, that's a testing tool. Good. Feature shows HTML code where images are present, but cannot generate screenshot and throws an error each time trying to generate one. Tools that use head as Chromium also cannot generate screenshots and crash on throws. Honestly, I don't care about the screenshot. Look at the rendered HTML. Looks the way you expected. You're good. That's it. The screenshot is just a nice to have again and using head as Chromium as a testing tool, that's a nice thing on top of it, but that might crash for completely unrelated reasons. So I wouldn't worry too much about it. Smaller pages, images are loaded fine. Search console shows the HTML has the images URLs, generates screenshots and tools. Yeah, again, doesn't matter. It sounds like your website, like the long pages are just very long and they exceed memory limits and that's okay. That's not a problem. In indexing, we don't care. It's absolutely. As long as the rendered HTML looks good, you should be fine. Why is there such inconsistencies? Welcome to the world of software. Computers are terrible. Is it possible that if Googlebot and Chromium are glitching out visual render? No, no. This would not be counted against you. No. Does Googlebot have this Chromium support native lazy loading? Yes, it does. All right, then is it possible to not load scripts on specific pages if you do not use it there? For example, recaptures only used on the register page. Yeah, that is absolutely possible. The things you wanna look for is, or the term you wanna look for is code splitting. Why is there always a big difference in lighthouse score between desktop and mobile? Because mobile is a lot slower. The CPU is startled because mobile processors are very different from desktop processors, both architecture-wise and performance-wise. So mobile is kind of like the lowest common denominator, and I would watch more for mobile than for desktop if I were you because mobile devices usually are not as powerful as desktop devices are. And one last question before I go back to the audience, we want to improve the load time of our pages. We implemented lazy loading with a placeholder as it is advised by Google guidelines, which Google guidelines. But okay, my issues are we're calling Google to crawl the page. First, Google does not render the screenshot view, that does not have any images in the screenshot view. The screenshot view doesn't matter as much. The rendered HTML is more important actually. The source of the images in the rendered HTML, aha, are still displayed as placeholder images. That very likely means that your lazy loading is not implemented correctly, and we are not seeing the actual image URLs. So you definitely want to look into that. And if we are rendering the placeholder URL, that is very likely an issue. Right, back to the audience. Any questions in the audience? If nobody else has questions, I can still. Yeah. Sure. So I'm asking about intrusive interstitials. And for starters, there's some documentation about mobile obtrusive or intrusive interstitials. I'm asking about desktop. Does desktop affect at all your ranking? Obviously, user experience, it can have effect, but I'm wondering if a page would get devalued on desktop. That's a ranking questions and I don't really answer ranking questions. Gotcha. So maybe the question that I do have regarding this does touch on JavaScript a bit and maybe you can help out. I'm wondering about, let's say you have a privacy policy like in California, you need the privacy policy. So that's a full page. And I'm wondering just in the background, how does Google know that this is a privacy policy and that it's okay as opposed to something that's more advertising or promotion related? I guess it depends a little bit on how your interstitial looks like. I think if it blocks the entire page, it's probably not fantastic if it's a pop-up or like a pop-over kind of thing, like a cookie banner or whatever, it's probably better. But that's actually a question that is not really with me. That's probably more for the general office hours with John. Okay, I'll bring it up. Awesome. Thanks. You're welcome. And I see that someone submitted something into chat that is also submitted on YouTube, but I'll take it anyway. Since rendering of widgets components via JavaScript are considered not useful for SEO, but developers are always happy in doing more rendering some client-side JavaScript as it helps in reducing there's like random notation in here. JavaScript as it helps in reducing the page load time with a big margin, what? But ever since ever going Googlebot has already been announced, so it is being used seeing the much updated version of Chrome as a result. We'll be able to see the JavaScript Ajax just an item. So will the widgets rendered by JavaScript? Oh my God. I don't know what you mean by widgets. If it's content that is put in the page by client-side JavaScript, we'll probably see it and then we'll probably also use it. So yeah, I mean, we are running the evergreen Googlebot. There's no problem with client-side rendering per se. If it's in the rendered HTML, we can use it. Depends a little bit on what you mean with widgets and visualization. Not 100% sure what that means. Right. Do you have any current documentation with recommendations for processes and tools to use for how SEOs should go about diagnosing issues with JavaScript-based websites? Yes, we do. If you go to developers.google.com slash search, then click on guides. There's an entire section on JavaScript. And my favorite one is go.gle slash js. Actually, now I have to see if, what was it? go.gle slash js.seo, js dash seo dash base. Screw it. I'll just post it in the chat. And actually, I'm not in the chat, but under the question. There we go. So if you go to developers.google.com slash search, you'll see our guides multiple on JavaScript SEO. And they are pretty much up to date because I keep them up to date. Some websites use different approaches or user behavior for desktop, mobile, and AMP. Uh-huh. On m.web, browsing user-layered approach, what is a layered approach? On click, a page layer opens with may lesser content against web version. OK. On desktop, regular click to URL approach. Redirects regular web page. On AMP, again, maybe click to URL since AMP doesn't give flexibility to do so. Will this be a not recommended or a good practice? I think this sounds more complicated than it's worth. I wouldn't do it. It's not per se bad. It's just it invites problems. It's more complicated. Like, the possible downside is much bigger than the possible upside of it, so I wouldn't do it. Um, that's Kieran's question that we answered earlier. That's Gautam's question that I tried to answer earlier. And then that's the questions for this. I know that last week we skipped, so I'll have a look at what was submitted last week. Our client has a website built on WordPress where he's using a very JS-dependent theme. Basically, after I disabled JavaScript, the website itself stops working, and there's almost no content in it. Is this a huge problem from SEO point of view? Is there something we can do other than switching themes of the website and therefore rebuilding it? It could be a problem. It doesn't have to be a problem. If you are seeing issues with the site being indexed and showing up in Google, then this might be the reason, because that sounds like it's less robust than it could be. But then again, if it works fine, then I wouldn't fix it, because fixing something that isn't broken usually means you're actually breaking it. However, I think reducing the dependence on JavaScript is always useful. So I would probably actually switch themes or at least understand why there is so much JavaScript and what this JavaScript does, and try to weed out the JavaScript that isn't absolutely essential. But that in itself is a lot of work as well. So you have to decide if the work invested there is worth it. And if it's not broken, I wouldn't fix it, because it's not broken. I recently have a client that had an amazing first input delay score, but terrible time to interactive and terrible total blocking time. How can this happen? I suppose when the JavaScript exploded overall, but split into smaller bundles, it might cause this, but not sure this is the cause. Also, if I have amazing first input delay, we still need to care about that time to interactive and time, total blocking time. That's a tricky one, because I'm not 100% sure how TTI and TBT are calculated these days. I think what I could imagine is that something does block the main thread in certain intervals, and that we are not picking this up when calculating the FID. And then it's one of these cases where measuring these things automatically is just really hard, and you have to see how it actually looks for a real user. And I would assume that if your first input delay is pretty low, and the user has an interactive page, then TTI and TBT don't, none of these metrics make sense when the real user experience is actually pretty good. Hypothetically, in a perfect world, that would never happen. In the perfect world, our metrics would reflect 100% what the user actually experiences, but surprise, surprise, we don't live in a perfect world, and these metrics are sometimes just off. But that's something that I would ask the Lighthouse team or open a bug in Lighthouse with the sample URL, because it sounds like an edge case that isn't quite usual or quite frequently happening, or maybe they know something that I don't know. But that's what I would think from the way that I rationalize about these metrics that this is an interesting edge case. Then we had the load event question, I answered that. If nothing can be painted before CSS is downloaded and the CSS object model is constructed, how can flash of unstyled content logically happen? Because things can be painted before the CSS object model is done. The reason for that is that the browser has a default style sheet, it has a deep, like if you don't specify any styles and you have like headline and the paragraph and the button and the link, all of these things have a default style, which is kind of unstyled content.  That is what I would consider a flash of unstyled content if it takes too long to actually get the resource from the server to actually start loading your CSS. That's why it's suggested to prevent that from happening by inlining the critical styles. So everything that is very, very layout critical, like how large our headlines, how roughly do our paragraphs look like, all this kind of stuff. So that the moment it starts parsing the HTML, it parses the inline CSS for the critical styles and then it continues parsing the actual content. So when it constructs the contents, it can automatically link that to the CSS object model and have the actual styles rather than like the default styles. So that's how that works. The DOM can start rendering before the CSS is loaded, hypothetically. All right, questions from the audience? Oh, few questions in the chat. All right, let's see. Do JavaScript websites consume additional crawl budget compared to a non-JS website with a similar number of pages? Do the non-JavaScript websites have an advantage over JavaScript websites in terms of crawl budget? Maybe is the answer to that. I say maybe because I don't wanna say it depends so often. It does depend. Assuming that you have a static website that has let's say five HTML pages and each of these five HTML pages has one image inside and one style sheet is like the same across all the pages. So like you have a style CSS that is loaded on all of these pages, all of these five HTML pages, and then you have five different images on each of these five HTML pages and they're static and there's no JavaScript involved. Then what would happen is we would do five requests for the HTML files. We would do one request for the CSS file because we cache it. So we request the first HTML file we request. We also request the image and we request the CSS file. We cache the image, we cache the CSS file. So when we request the second HTML file which loads the same CSS file that we cached here, we're not gonna request it again. We do request the other image because it's a different image. So okay, so that would mean we have five HTML files, we have five image files. So that's 10 requests. And then we have one style CSS file. That's the 11th request. So that these five pages would cause 11 requests which is kind of what your crawl budget is or affects. If you have a JavaScript in there that adds some funky functionality and it's the same JavaScript on all of these pages or three of these pages have the same JavaScript. The other two doesn't even load any JavaScript. Then the same thing with the CSS would happen. If all five HTML pages have the same JavaScript applied to them and it doesn't make any additional network requests, then we would download that JavaScript file, we would cache it and then the other pages would just use the cached version of that. If this JavaScript however does network requests, API requests, loading additional images, whatever, these requests also count against the crawl budget. But let's say you have a JavaScript that loads, I don't know, loads man, a counter, like a visitor counter from a network database on an API or whatever. It makes an API call, it makes the same API call on all of these pages. Again, we would make this API call once and then cache the result for the other pages. So it does have impact on your crawl budget, but it doesn't automatically mean that you have a problem. Honestly, most pages, unless most sites unless they are like sites with like tens of millions of URLs or sites that have a really bad server don't really hit this problem. So I wouldn't say that JavaScript has a huge impact on crawl budget to be honest, it can have a bit of an impact on crawl budget, but I would say it's not as relevant as people might think it is. Next question, if the website is completely blocked with no possible user engagement when JavaScript is disabled and if we display a message, please enable JavaScript. Yeah, that's kind of bad. I mean, not for SEO necessarily, if you say like, oh, you don't have JavaScript enabled and screw you, but it just wraps me the wrong way, the sense of if JavaScript goes wrong and JavaScript is more likely to go wrong than HTML downloads or CSS downloads because these things can be starting to have an impact as they download, whereas JavaScript has to be fully downloaded, then parsed and then executed. It's just more potential for things going wrong. It's not a problem per se. It also isn't exactly great for the user, especially if they decide to browse without JavaScript or there is a problem with your JavaScript. I wouldn't fix it if you don't experience problems or bad feedback from users, but if I were to build a website today, I wouldn't build it that way, I think. We used to do that in 2012 or something. I remember that was like the default thing to do and it felt wrong back then and it does feel wrong today if you ask me, but there's no inherent SEO downside or any inherent problem with it from Google's perspective, at least. Why field data and lab data have differences for page speed? Well, surprise, they are not the same thing. Field data is coming from real users, whereas lab data comes from a quite strong machine with probably good internet from somewhere around the world. So you might not see the same results if the lab data is from, I don't know, Mountain View or actually, let's make an example. If I run my server here in Switzerland and my lab data comes from Switzerland, then that's gonna be really fast, like we're gonna have a fantastic network connection in between the two. If the lab data is gathered on my MacBook here with has, I don't know how many cores and how much memory and I don't even, like it has quite a bit of power under the hood and it has a fantastic network connection. It's also a very short network connection if the like Zurich or Switzerland is a small country. So the time, the physical time it takes to go to the server and the other end of Switzerland and come back is minimal. So my lab data would look fantastic if my users are actually in the US and they are in rural US where they only have mobile connections and they might not be on a fancy latest generation laptop but they might have a laptop that has, I don't know, seen the likes of Windows XP or something. Like it's an older laptop. Then this field data wouldn't look as great because A, the data has to travel across the Atlantic and back. Well, actually it comes from the other side of the Atlantic, it goes back over the Atlantic. That takes longer. Their connection is probably spotty and slow. That makes everything slower. And then their laptop isn't very fast and fancy. So executing all my JavaScript is very likely also going to be slower. In that case, my lab data looks amazing. And then my field data, because my users are sitting in the other end of the world, looks terrible. That's what happens because the lab data is only synthetic.  And then you have field data, which surprisingly gives you the actual thing that people are experiencing. So if you know that you are serving users on slow old phones or on rural spotty internet connections, this is what happens. This is where the field data looks a lot worse than what you see in lab data. And that's a general problem. Developers usually work with fantastic internet connections on modern laptops. And then the real world user is on an old iPhone 2 somewhere in rural northern Germany where you have edge internet connection if you are lucky. And then everything looks terrible for them.  It's it loads within a second for us. It's like, yeah, for you, but not for your actual users. So again, field data is probably a better indicator for how real users are experiencing your website than lab data. Because lab data is literally just someone's server making a request to your thing. And if that server happens to be quite beefy, then you get pretty good looking numbers, but then the real world isn't as beefy and nice. All right, do we have any other questions? I've got one if that's okay, Martin. Yeah, sure. Yeah, I watched your thing yesterday with only about the render I say that's very good. You mentioned that you'll look at the render tree rather than the, you know, in general. Is that something most people would actually need to worry about? And if so, is there something that we can look at from a Google perspective other than maybe just a screenshot in mobile friendly? So, yeah, that's a good question. So what I said yesterday in the only webinar is that we do use the render tree rather than painting the actual pixels. But that's not something that you normally need to worry about unless there are bigger problems that culminate in a problem with layouting. Normally it is enough to look at the rendered HTML to see if your content is there. If the content roughly looks in a real browser like you would expect it to look like and then you should be fine.  And I literally mean like everything is screwed up that the layouting becomes an issue that like topples over our ability to make guesswork happen. But if Google search needs to guess things on your website like, is this the main content? I don't know because everything is in one large div. Then you are already on a very, very dark path and should definitely backtrack. So normally you don't have to worry about this. It's an implementation detail. It's quite geeky to begin with and no one has to understand this or worry about this realistically. Awesome. More questions from the audience? You can also use the chat. Chat is perfectly fine. I'm scrolling down. Oh yeah, here we go. In Google search console, we see this under URL inspection. Crawled page, more info, page resources, 36 out of the 73 couldn't be loaded. Some have a label other error. How can we debug this error further? Ah, you can't really. That's the unfortunate thing here. Two things. First thing, a resource not loaded isn't per se a problem. It just means that we didn't load it. If you have things like Google Analytics on the page, we are very likely not loading this one because it doesn't really add benefit to our rendering. So a resource not loaded isn't a problem per se. The other error is the most dreadful possible error because it means something that you don't really have an option to act on has happened and most likely what happens. So most of the time other error means we don't want to let you wait for an hour until we actually get a spot to download this resource through our infrastructure. So we are cutting it short here. I know that's not fantastic, but that's a trade-off that we have to do with the testing tools. The indexing infrastructure can afford to just wait for things. We also cache things heavily. Both of these things are not available or not feasible in a testing tool, right? We want to show you the latest thing according to what is on your page. So we are not using caching. So we have to request everything. The way that we are building the testing tools is we're trying to be as close as possible to the actual indexing infrastructure, which means we're using the indexing infrastructure. However, the way the indexing infrastructure is designed is for background batch usage. So like Googlebot basically has infinite amount of time to wait for things, right? We can hypothetically say like download this thing and then it's okay if that download is only, like if this is in a queue for an hour or something and then it actually gets downloaded. That's fine for indexing because it doesn't really matter. The rest of the pipeline will run as the download has happened. We can't let you wait an hour in front of the mobile friendly test until we wait for actually getting this resource. Images are very likely not necessary for the actual rendered HTML to show up correctly. It's just for the screenshot.  So as long as it's images, as you say, like most of them or some of them are images, doesn't matter. We are not really downloading the images in indexing either as these for main web crawling. We don't have to do that because we are only interested in the URL of the image really and the out text and the context that the image is in rather than the actual image pixel data. So if that doesn't show up on the screenshot, that doesn't mean much. As long as the image URL is correct in the rendered HTML, you're good. On slow connections, I'm getting more blocking time due to AdSense ad. So what can we do? I would ask the ads team. I don't know about AdSense. There's probably something that they allow you to do to make things faster, but I don't know. So I would ask the AdSense folks for this. All right. Any other questions? Because I think we have exhausted our YouTube questions. At least I'm not seeing any others. No, answer that. Not going to answer that one. Yeah. All right. Last chance for questions. Five, four, three, two, one. If there are no further questions, then I'd like to thank you all for joining the recording. Thank you all for watching this later on YouTube. And thanks for being fantastic, build cool stuff on the web and stay safe, stay healthy. Bye-bye. Thanks for joining.