Year in Search Central 2021

So big events, as you said, had these two factors to them.


Year in Search Central 2021

One was that we could give a talk


Year in Search Central 2021

and reach a large audience of people in one go


Year in Search Central 2021

and share information from our perspective in one go.


Year in Search Central 2021

And then the hallway track with this entire building


Year in Search Central 2021

relationships, getting to know each other,


Year in Search Central 2021

finding out what isn't working so well, what people are


Year in Search Central 2021

actually struggling with on a day-to-day basis,


Year in Search Central 2021

or what they are achieving on a day-to-day basis


Year in Search Central 2021

and want to share.


Year in Search Central 2021

And I do hope that we are getting that back, because I


Year in Search Central 2021

think that's immensely valuable.


Year in Search Central 2021

And it just does not work so well when transported online.


Year in Search Central 2021

I don't know why, but that's what it is.


Year in Search Central 2021

OK.


Year in Search Central 2021

So basically, you would go to the next big event


Year in Search Central 2021

and just lurk in the hallways and chat with people, ideally.


Year in Search Central 2021

Yeah.


Year in Search Central 2021

Ideally.


Year in Search Central 2021

If it's safe to do so, sure.


Year in Search Central 2021

Sure.


Year in Search Central 2021

Well, I mean, the safe to do so is kind of a requirement


Year in Search Central 2021

at some point.


Year in Search Central 2021

But hopefully we'll get there.


Year in Search Central 2021

So what about podcasts like these?


Year in Search Central 2021

Do you think we should be doing more of this?


Year in Search Central 2021

Like more episodes or release?


Year in Search Central 2021

More episodes of podcasts.


Year in Search Central 2021

Is a podcast kind of like listening


Year in Search Central 2021

in to a hallway discussion?


Year in Search Central 2021

I mean, it's more like being the fly on the wall, right?


Year in Search Central 2021

Rather than a hallway discussion.


Year in Search Central 2021

Well, it's kind of like listening in.


Year in Search Central 2021

Eavesdropping.


Year in Search Central 2021

I mean, we are having eavesdropping


Year in Search Central 2021

on our conversation, which is nice, I think.


Year in Search Central 2021

OK.


Year in Search Central 2021

So we should do more of these.


Year in Search Central 2021

It doesn't sound like you guys are convinced.


Year in Search Central 2021

You're like, eh.


Year in Search Central 2021

Well, I mean, so the nice thing about this


Year in Search Central 2021

is that the cadence we have right now,


Year in Search Central 2021

we usually have something to talk about.


Year in Search Central 2021

And the whole idea is to let people


Year in Search Central 2021

in on the behind the scenes bits and pieces


Year in Search Central 2021

and to be very genuine as well, which


Year in Search Central 2021

means minimal planning ahead.


Year in Search Central 2021

But if we want to speed things up,


Year in Search Central 2021

then that means more planning ahead.


Year in Search Central 2021

But then the tricky question becomes


Year in Search Central 2021

is, how do we plan ahead yet keep the flexibility?


Year in Search Central 2021

I think we can have a list of things


Year in Search Central 2021

that we want to talk about anyway


Year in Search Central 2021

and then push that back whenever we have something current


Year in Search Central 2021

that we want to talk about.


Year in Search Central 2021

There is already a delay between what we talk about


Year in Search Central 2021

and when it comes out into the public eye,


Year in Search Central 2021

or actually into the public ear, rather,


Year in Search Central 2021

this being a podcast and all.


Year in Search Central 2021

But yeah, I don't know.


Year in Search Central 2021

I don't know how I'm feeling about speeding things up.


Year in Search Central 2021

Oh my gosh.


Year in Search Central 2021

That sounds very reluctant.


Year in Search Central 2021

What about you, Gary?


Year in Search Central 2021

Should we do more podcasts, or should we


Year in Search Central 2021

switch to videos again?


Year in Search Central 2021

Well, I don't like videos, so there's that.


Year in Search Central 2021

I have a strong preference for podcasts,


Year in Search Central 2021

at least recording-wise.


Year in Search Central 2021

I'm with Martin on this.


Year in Search Central 2021

Basically, we are busy folks because I'm baking cookies,


Year in Search Central 2021

and Martin is doing stuff, and John is working.


Year in Search Central 2021

If we would need to do more, then that just


Year in Search Central 2021

means that we need more time to, for example, bake cookies,


Year in Search Central 2021

which is hard because we only have 24 hours in a day.


Year in Search Central 2021

But I would be up for it, at least to try it and see


Year in Search Central 2021

how it goes.


Year in Search Central 2021

Maybe people want more podcast episodes,


Year in Search Central 2021

and I definitely know that we have collective knowledge


Year in Search Central 2021

that we could talk about search for days and days,


Year in Search Central 2021

and we still wouldn't run out of topics.


Year in Search Central 2021

Give it a try and see how it goes, maybe.


Year in Search Central 2021

Fine.


Year in Search Central 2021

We could ask the audience.


Year in Search Central 2021

No, don't give people the idea that they have power over us.


Year in Search Central 2021

Of course they have power.


Year in Search Central 2021

This is a democracy, Martin.


Year in Search Central 2021

We will have the majority determine whether or not


Year in Search Central 2021

you will do a podcast.


Year in Search Central 2021

Internet, no.


Year in Search Central 2021

This is Sparta.


Year in Search Central 2021

OK.


Year in Search Central 2021

Well, I mean, it's like if you're listening to this


Year in Search Central 2021

and you have comments on whether or not


Year in Search Central 2021

we should do more podcasts or not,


Year in Search Central 2021

or what kind of podcasts we should do more of,


Year in Search Central 2021

it's like make sure to drop some comments


Year in Search Central 2021

and send us some tweets or something along the way


Year in Search Central 2021

to kind of motivate Martin and Gary to actually join in more.


Year in Search Central 2021

John, seriously.


Year in Search Central 2021

Yes.


Year in Search Central 2021

Who do you think is listening at the 30-somethings minute?


Year in Search Central 2021

Who?


Year in Search Central 2021

Yeah, everyone has moved on to other things, hopefully.


Year in Search Central 2021

I'm pretty sure Barry is listening to this.


Year in Search Central 2021

Hi, Barry.


Year in Search Central 2021

If you're listening to this.


Year in Search Central 2021

Hey, Barry.


Year in Search Central 2021

Cool.


Year in Search Central 2021

And I'm sure there are at least seven other people.


Year in Search Central 2021

At least seven.


Year in Search Central 2021

So we'll get seven comments at least, maybe, hopefully.


Year in Search Central 2021

I'm sure.


Year in Search Central 2021

I'm sure it'll be good.


Year in Search Central 2021

I mean, I really enjoy doing these podcasts


Year in Search Central 2021

because it's a little bit easier than doing


Year in Search Central 2021

kind of the more formal videos and the more formal content.


Year in Search Central 2021

It's a little bit easier to get, I don't know,


Year in Search Central 2021

less formal input from you all and kind


Year in Search Central 2021

of being able to also show that, well, just because Google says


Year in Search Central 2021

something doesn't mean that it's all unanimous


Year in Search Central 2021

and everyone agrees and everyone wants


Year in Search Central 2021

to do exactly the same thing.


Year in Search Central 2021

Sometimes there are different opinions internally at Google


Year in Search Central 2021

and finding out what is actually right and what is wrong.


Year in Search Central 2021

So you never really know ahead of time.


Year in Search Central 2021

And that's, I think, kind of the charm of the podcast format.


Year in Search Central 2021

And we can still give away information


Year in Search Central 2021

and see it being picked up by, for example,


Year in Search Central 2021

search engine roundtable.


Year in Search Central 2021

Cool.


Year in Search Central 2021

Well, watch out to see what everyone


Year in Search Central 2021

has to write about this episode.


Year in Search Central 2021

And hopefully they say, you should do more of this.


Year in Search Central 2021

And don't fire John or Gary or Martin.


Year in Search Central 2021

Interesting conclusion.


Year in Search Central 2021

OK.


Year in Search Central 2021

Well, thanks for joining us here, folks.


Year in Search Central 2021

We've been having fun with these podcast episodes.


Year in Search Central 2021

And I hope you, the listener, have


Year in Search Central 2021

found them both entertaining and insightful as well.


Year in Search Central 2021

Feel free to drop me a note on Twitter


Year in Search Central 2021

or chat with us at one of the virtual events


Year in Search Central 2021

whenever they happen to take place


Year in Search Central 2021

if you have any thoughts on the podcast and the content


Year in Search Central 2021

that we could be covering here.


Year in Search Central 2021

And of course, don't forget to like and subscribe.


Year in Search Central 2021

So thank you and goodbye.


Year in Search Central 2021


User-generated content on your site #AskGoogleWebmasters

Today's question is from Amit Kumar, who's asking,


Google ranks web pages based on content relevancy and quality,


among other factors.


Does this apply in the case of user-generated content


as well?


It's good to get your user-generated content


for this series.


Thank you.


User-generated content can take lots of forms,


from comments on the bottom of your pages


to discussions between users to complete pages written


by users.


Overall, Google doesn't differentiate


between content you wrote and content your users wrote.


If you publish it on your site, we'll


see it as the content that you want to have published.


And that's what we'll use for ranking.


After all, it's your website, right?


So if you have a large amount of user-generated content,


make sure it meets your standards for publishing


content on your website.


A simple way to do this is to block those pages


from being indexed by default and to only allow


them to be indexed if you're happy with the quality.


For example, you could block them


with a no-index robots meta tag, which


you remove once you're happy.


Figuring out how much it takes for you


to be happy with the content is up to you.


Some sites collect information on how happy other users are


with the content, which might be useful for this.


Finally, one thing to keep in mind


with user-generated content is that by default, you probably


can't vouch for the links that were added.


For these, we have a way of telling us


that these links are user-generated content


with the rel="ugc link attribute."


I hope you found this useful.


Thank you for submitting.


I'll link to the details in the description below.


And see you next time on Ask Google Webmasters.


JavaScript SEO office hours June 10th, 2020

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 asks if I run a URL that has lots of JavaScript on the page,


and 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 I had 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 than that,


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're rendering there or what we are seeing there


is what you expect us to see.


GARY GILLESPIE-MEYERIASLALHUISSICIOUSO.


Yeah, because we started doing this quite a while ago,


I think, before the new version of Search Console.


So that wasn't fully available at the time.


And what we were doing was we were


seeing within the actual search results page for the website


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?


MARTIN SPLITT ANDERSON


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.


MARTIN SPLITT ANDERSON OK, that's fair enough.


Yeah, that's fine.


Then that's my question answered.


Thank you.


GARY GILLESPIE-MEYERIASLALHUISSICIOUSO.


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 stylesheets and images.


But what is the definition of the whole page has 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 stylesheet 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, like 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.


So if we have seen a script and the stylesheet


and two images and a video and an iframe, all of that


would have to finish loading before the load event fires.


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 stylesheet, every image, every video, everything.


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?


Right.


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 pane,


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.


AUDIENCE 1 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.


Then the rendered goes to the inner page.


So would you then prioritize that over critical content?


MARTIN SPLITTENBERG 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 pick 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 collection


is the desktop URL.


And I have a separate mobile site with m-dot.


And I'm suspecting that the canonical is the cause of this.


So instead, I would expect to see the m-dot as the canonical.


With m-dot and mobile-first indexing, there's lots of variables in the error.


You're welcome.


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 you 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 nginx and redis, the CMS's WordPress.


Optimizations are server-level caching,


mini-fi, 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, 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 headless Chromium also cannot generate screenshots


and crash on throwers.


Honestly, I don't care about the screenshot.


Look at the rendered HTML.


If the rendered HTML looks the way you expect it, you're good.


That's it.


The screenshot is just a nice to have again.


And using headless 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 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 OK.


That's not a problem.


In indexing, we don't care.


It's absolutely not.


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.


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, recapture is only used on the register page.


Yeah, that is absolutely possible.


The things you want to look for is,


or the term you want to 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 throttled 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 OK, my issues are we're calling


Google to crawl the page first.


Google does not render the ScreenshotView.


It does not have any images in the ScreenshotView.


The ScreenshotView doesn't matter as much.


The rendered HTML is more important, actually.


The source of the images in the rendered HTML


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.


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 question, and I don't really


answer ranking questions.


Got you.


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 the, 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 OK, 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,


that's probably not fantastic.


If it's a pop up or 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.


OK.


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 renderings


on client side JavaScript, as it helps in reducing the,


there's like random notation in here.


JavaScript, as it helps in reducing the page load


time with a big margin.


But ever since Google, evergreen Googlebot


has already been announced, so it


is being used in the much updated version of Chrome.


As a result, we will be able to see the JavaScript


Ajax version items.


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 digits


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 SEO 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 goo.gle slash js.


Actually, now I have to see if, what was it?


goo.gle slash 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.


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.


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 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.


The possible downside is much bigger


than the possible upside of it.


So I wouldn't do it.


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 disable 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's loaded 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,


do I still need to care about that time


to interactive and 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 a 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 a 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 un-style 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.


If you don't specify any styles, and you


have a headline, and a paragraph, and a button,


and a link, all of these things have a default style,


which is kind of un-styled content.


I mean, you get a sans font from the system,


and headlines are big and black, and then


links are blue and underlined and stuff like that.


That is what I would consider a flash of un-styled 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 are 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 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, a 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?


Will 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 want to 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 that


is the same across all the pages.


So 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 are 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 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 going to request it again.


We do request the other image because it's a different image.


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 these five pages would cause 11 requests,


which is kind of what your crawl budget 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, most sites,


unless they are sites with 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,


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,


then screw you.


But it just rubs 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 the default thing to do.


And it felt wrong back then, and it does feel wrong today,


if you ask me.


But there is 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 let's make an example.


If I run my server here in Switzerland,


and my lab data comes from Switzerland,


then that's going to be really fast.


Like, we're going to have a fantastic network


connection in between the two.


If the lab data is gathered on my MacBook here,


it has I don't know how many cores and how much memory,


and I don't even.


It has quite a bit of power under the hood,


and it has a lot of memory.


It has a lot of power under the hood,


and it has a fantastic network connection.


It's also a very short network connection.


Like, Switzerland is a small country,


so the physical time it takes to go


to the server in 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 a few 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.


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.


It's only an approximation of what


happens in the real world.


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.


And you're like, I don't understand


why our users are complaining that everything is slow.


It loads within a second for us.


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 a quick one, if that's OK, Martin.


Yeah, sure.


Yeah, I watched your thing yesterday


with only about the render SEO.


That's very good.


You mentioned that you'll look at the render tree


rather than the in general.


Is that something most people would actually


need to worry about?


And if so, is there something that we


can look at it 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 one-way 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 the 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.


There are very rare cases where everything on a website


is so screwed up, and I literally


mean everything is screwed up, that the layouting becomes


an issue that 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.


OK, cool.


Awesome.


More questions from the audience?


We 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 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, which 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


to our infrastructure.


So we are cutting it short here.


I know that's not fantastic, but that's the 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 the testing tool.


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 Googlebot basically has infinite amount of time


to wait for things.


We can hypothetically say, download this thing,


and then it's OK if that download is only


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 images are the first to actually get kicked out,


really.


So as long as it's images, as you say, most of them are,


or some of them are images, doesn't matter.


We are not really downloading the images in indexing either,


at least 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 alt 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.


All right.


On slow connections, I'm getting more blocking time


due to AdSense ads.


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.


Any other questions?


Because I think we have exhausted our YouTube questions.


At least I'm not seeing any of those.


There we go.


I'll answer that.


I'm not going to answer that one.


Yeah.


Last chance for questions.


5, 4, 3, 2, 1.


All right.


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.


AMP status report in Search Console - Google Search Console Training

Hi, I'm Daniel Weisberg, Search Advocate at Google.


And today I'll talk about how to use Search Console


to improve your AMP implementation.


By the end of this video, you should be able to find AMP issues


Google discovered in your website, fix them,


and ask Google to validate your fixes.


How to use Search Console to improve AMP implementation


Before I discuss the Search Console reports,


I would like to give a quick intro to AMP,


just in case you're not familiar with it.


AMP, or Accelerated Mobile Pages,


is an open-source HTML framework that provides a straightforward way


to create web pages that are fast, smooth-loading,


and prioritize the user experience.


It can be used to easily create websites, stories, ads, and more.


There are several reasons to use the AMP framework.


Web page speed improves the user experience


and core business metrics.


Building AMP pages is simple and reduces developer overhead.


AMP has lots of components that can be used as website building blocks,


and they're already optimized for best performance.


Besides the general benefits of the AMP framework,


there are additional benefits for AMP on Google Search,


such as serving from the Google cache,


and more opportunities to appear in AMP-related experiences.


If you want to learn more about how AMP looks in Google Search results,


check our developer documentation linked in the video description.


When Google detects AMP on your website,


you'll see a report in Search Console detailing any AMP issues


that Google found on your pages.


That can be really handy when reviewing your AMP implementation.


It will help you focus your efforts on the most important tasks.


The top-level view shows crawled AMP pages


with any issues found by Google.


The default chart shows the trends for AMP errors,


but you can click Valid with Warnings and Valid to see their trends too.


In addition, you will see a checkbox


to add the number of impressions your AMP pages got on Search.


This can be very helpful to understand how issues affect your results.


Below the chart, you'll find a table with issues grouped by type.


AMP pages that show an error cannot be shown in Search results.


For example, your AMP page is blocked by robots.txt,


custom JavaScript is not allowed,


or the HTML tag has an invalid layout specified by its attributes.


AMP pages with Warnings are indexed and can be shown in Google Search results,


but they might not be shown in AMP rich results


or the top source carousel.


Warnings include non-optimal pages


or use of deprecated features that may become errors in the future.


Valid AMP pages work as expected for users


and can be included in AMP-related features.


So if everything is green, it means you're doing a great job.


By default, issues are sorted by a combination of severity,


validation state, and number of pages affected.


If you see an error that seems like a result of a bad template,


fix it first.


Then continue fixing other issues that are unique to each page.


Click a specific issue to see more details


with a link to learn more about how to fix it


and a process to notify Google about your fixes,


which I'll talk about in a minute.


You'll also find a list of example URLs affected by this issue.


You can click a specific URL to find the HTML


and exact location of the offending code.


If you want to see a full list of errors


for a specific URL that is shown in the report,


click the Inspect icon next to the URL.


This will open the URL inspection already discussed in this video series.


This test pinpoints all errors, not just the current issue,


and provides a code explorer highlighting the errors


and providing more information.


It is possible that an error has been fixed in the live page,


but it's still listed as an error because it has not been recrawled.


You can check that by testing the live version of your page


in the URL inspection results.


If that's the case, request validation through the AMP issue page.


Now that you know what needs to be fixed, you have two options.


Make the required code changes yourself,


or share the details with a developer


that can perform code changes to your website.


You can do that by grabbing a link using the Share button


from any issue page.


Know that the sharing link grants access only to the current page,


plus any validation history pages for this issue.


It does not grant access to other pages for your resource


or enable the shared user to perform any actions


on your property or account.


You can revoke the link at any time by disabling sharing for this page.


It might also be a good idea to use the AMP test tool,


where in addition to testing a specific page,


you can also upload a piece of code to check for issues.


These can be helpful to debug issues for new pages.


But note that the tool will check your general AMP implementation


without specific information about Google indexing.


After you or your developer fix the error,


confirm the fix by inspecting the live version of the page.


Then click Validate Fix from the AMP issue page


and Google will validate your changes.


The validation process can take several days


and you will receive progress notifications by email.


If the current instance exists in a sample of pages,


validation ends and the validation state remains unchanged.


If the sample pages do not have the current error,


validation continues with state started.


When all error or warning URLs have been checked


and the issue count is zero, the issue state changes to past.


You can see the progress of a validation request


by clicking the validation details link in the issue details page.


To learn more about the AMP issues on our pages,


missing pages troubleshooting, validation stages,


and other details about this report,


visit the Search Console Help Center.


I hope this video helped you understand how to optimize your website


by improving AMP warnings and errors.


Your users will thank you for that.


In the next episode, I'll talk about how to use Search Console


to submit sitemaps to Google,


how to review your sitemap submission history,


and how to find errors that Google encountered


when parsing your submitted sitemaps.


Don't forget to subscribe to the Google Webmasters YouTube channel,


where we'll be publishing lots of Search Console videos.


Stay tuned.


This is Webby. This is Ampi.


They're going for a run.


7 ways to verify site ownership - Google Search Console Training

Hi, I'm Daniel Weisberg, Search Advocate at Google.


And in this video, I'll talk about how to activate Search Console for your site


so that you can get access to your Google search data.


There are seven ways to verify your site ownership in Search Console,


providing you with a wide range of options to choose from.


This video should help you find the method that works best for you.


Verification


Verification is the process of proving to Google that you own a property.


This is needed in order to make sure you are the owner of the website


and to prevent others to see your private search data.


Proving ownership on the web is simply demonstrating the ability to update


and make a small, non-visible change to your website.


If you're the site owner, this should be a very simple operation for you.


It could literally take only a few minutes.


As the title of the video suggests,


Search Console supports seven verification methods.


DNS Record, HTML File Upload, HTML Tag, Google Analytics Tracking Code,


Google Tag Manager Container Script, Google Sites, and Blogger.


First of all, for all methods described here,


you'll start in the same place.


Open your Search Console account


and click Add Property in the Properties list.


If you have never verified a property,


the first time you log into Search Console,


you'll find our special wizard asking you to verify a property.


If it's your first or tenth verification,


when you click to add a new property,


you'll be asked what property type you want to create.


You have two options, Domain Property and URL Prefix Property.


I suggest creating at least one domain property to represent your site,


as it is the most comprehensive view of your website information.


It will include all URLs in all subdomains


and across HTTP and HTTPS.


It requires you to add a DNS record in your domain name provider,


but it's worth your time.


URL Prefix Property verification is usually a bit simpler,


as you have multiple verification methods,


such as using your existing Google Analytics or Tag Manager account.


URL Prefix Properties also make sense


if you want to view a section of your site separately.


For example, if you work with a consultant on a specific part of your site,


you might want to verify this part separately


so that you can limit access to your data.


Now, let's talk about each of the verification methods available to you.


If you're feeling sleepy, now's the time to pause and go get a coffee.


How to add a DNS Record


DNS verification requires you to add a DNS record


in your domain name provider.


This is the only method supported for domain properties.


So I'll demonstrate DNS record verification,


by creating a domain property.


But know that you can also use DNS record verification


on URL prefix properties.


Add your domain to the domain option, as shown in the screen,


and click Continue.


In the instructions dialog, you'll see two options.


If your domain register is listed in the instructions dropdown,


you'll be walked through an easier, automated process to verify your site.


For example, if your DNS provider is GoDaddy,


choose it from the list and click Start Verification.


This will lead you to their login page,


where you'll need the credentials used in GoDaddy.


After logging in, click Authorize,


and you'll be redirected to Search Console.


But don't worry if the verification doesn't work immediately.


Just wait a few hours or a day,


and try verifying again by choosing it from the properties list.


Sometimes, DNS record changes can be slow.


If your domain name provider is not in the list,


you'll need to follow written instructions in the Help Center


to copy your DNS text record into your domain provider.


Start by copying the text record from the dialog after entering your domain.


Then, click Full Details to open up the Help Center.


You'll see the full process documented there.


We have instructions for a lot of domain providers.


Find yours in the list and click the link for more information.


Now follow the instructions for your specific provider.


If you're asked to provide a Google security token,


that's the token you copied from Search Console's verification dialog


a minute ago.


After you change your DNS record,


go back to Search Console and click Verify in the Verification pane.


If the verification doesn't work immediately,


wait a few hours or a day and try again,


as the change may take some time to take effect.


Just choose the unverified property from the properties dropdown,


and it will try to verify you automatically.


To stay verified, don't remove the DNS record,


even after verification succeeds.


If you perform the steps above and your verification does not succeed,


check the Full Details link mentioned previously


to learn about potential errors.


You can find out more about those errors


and how to handle them in the Help Center.


In order to verify your website using HTML file upload,


you'll need to have permission to upload a file to your website


where it can be accessed by a browser.


After you click Add Property,


add your website URL under the URL prefix option and click Continue.


Expand the HTML file section where you'll find the File Download button.


Download your HTML verification file


and upload it to the root directory of the property you want to verify.


For example, if you want to verify www.example.com,


then the root directory is the homepage.


If you want to verify www.example.com slash party,


then the root directory is slash party slash.


In this case, you would upload the file to slash party slash


and all child directories would be verified.


Note that you can use this file in any site you want to verify.


It's personalized to your user and can be reused.


Once you complete this step, click Verify in Search Console.


If you perform the steps above correctly,


the verification should work immediately.


If it doesn't, click the Full Details link


to learn about potential errors.


You can find out more about those errors


and how to handle them in the Help Center.


In order to verify your website with an HTML tag,


you'll need permission to edit the source code of your website's homepage.


After you click Add Property,


add your website URL under the URL prefix option and click Continue.


Expand the HTML tag section to find the meta HTML tag


with a personalized key.


Copy the tag and paste it into your homepage head tag.


Make sure not to change the text.


Verify that the tag is present on your live page


by visiting your homepage and checking the page source text


to confirm that the tag is present.


verification should work immediately.


If it doesn't, click the Full Details link to learn about potential errors.


In order to verify your website using the Google Analytics tracking code,


you'll need an account with Google Analytics that uses the same Google account.


You must have at least added permission on the Google Analytics account.


If you're not sure which permission you have,


check the Google Analytics Help Center.


Before verifying, ensure that your homepage


has the Google Analytics tracking code in the head section of the page.


Although your Analytics tracking code might work for Analytics


in the body section as well, for Search Console verification,


it must be in the head section.


Open your homepage in a browser,


look at the page source code,


and confirm that the tag is present in the head tag of the page.


After you click Add Property,


You must be logged into Search Console


with the same Google account that you use for Google Analytics.


If you perform the steps above correctly,


verification should work immediately.


You can find out more about those errors


and how to handle them in the Help Center.


The Google Analytics tracking code will be used only to verify site ownership.


No Google Analytics data will be accessed following this process.


If you're looking to configure Search Console data in Analytics,


that's an entirely separate process.


Check the link below to learn more.


In order to verify your website with the Google Tag Manager container snippet,


you'll need published permissions to your container in Google Tag Manager.


You'll also need to be logged into Search Console


with the same Google account that you use for Google Tag Manager.


If you're not sure which permissions you have,


check the Google Tag Manager Help Center linked below.


Before verifying, ensure that your homepage


has the NoScript portion of the Tag Manager code


immediately after the opening body tag.


If it does not, verification will fail.


Open your homepage in a browser,


look at the page source code,


and confirm that the tag is present


and immediately after the body tag with nothing in between.


After you click Add Property,


add your website URL under the URL prefix option and click Continue.


Expand the Google Tag Manager section,


where you'll find a button to verify.


If you have the necessary permission,


your verification should work immediately after clicking it.


If you perform the steps above correctly,


verification should work immediately.


If it doesn't, click the Full Details link to learn about potential errors.


You can find out more about those errors


and how to handle them in the Help Center.


The Google Tag Manager container ID will be used only to verify site ownership.


No Google Tag Manager data will be accessed following this process.


In order to verify your classic Google site,


you must be logged into Search Console


with the same account used to manage your site.


Click Add Property, add your website URL under the URL prefix option,


and click Continue.


That's it.


Your Google site should be verified automatically after this step.


If you have a new site or a site with a custom domain URL,


you will not be automatically verified.


If that's the case with your site, you should use the Google Analytics method.


If you're not sure whether your site is classic or new,


check the link below in the site's Help Center.


In order to verify your website with Blogger,


with the same account used to manage your blog.


After you click Add Property,


add your website URL under the URL prefix option, and click Continue.


Your blog should be verified automatically after this step.


Wow, that was a lot.


But before I leave you,


I would like to suggest you to try and verify your website


with more than one verification method,


just in case one of your existing verification methods fails.


Verification methods are checked periodically by Google,


and if all verification methods for a property fail,


your access to that property will expire.


But if you lose access to your account, don't worry.


We have your back.


You can always re-verify with your user


or verify a new owner using one of the methods described in this video.


Every Search Console property requires at least one verified owner,


but I recommend companies to have more than one owner,


as employees may change roles or leave the organization.


So it's good practice to have several verified owners in Search Console.


When it comes to security,


account owners will always be able to see the list of all owners and users


verified to that site,


as well as the verification methods for each owner.


You can then optionally un-verify previous owners


by removing their verification token.


For example, removing the HTML tag from the site


for HTML tag verified owners.


Make sure to check your list of owners once in a while


so that you remember to remove previous employees


or agencies you have worked with in the past.


That's it.


Hopefully, now you have a better understanding


of how to verify websites on Search Console.


Now choose your method and get to work.


In the next video, I'll discuss the performance reports in Search Console,


which you can use to monitor your site's performance in Google Search.


Don't forget to subscribe to the Google Webmasters YouTube channel,


where we'll be publishing lots of Search Console videos.


Stay tuned.


Google Webmasters


Let’s talk JavaScript

I bet you're all wondering why I gathered you here today, Martin.


Let’s talk JavaScript

I was about to say, like, who are you talking all?


Let’s talk JavaScript

Because it's just me.


Let’s talk JavaScript

It's me and you.


Let’s talk JavaScript

Oh.


Let’s talk JavaScript

Oh, no, we lost John.


Let’s talk JavaScript

So it appears that John doesn't love us anymore and he had to bail on us and not record podcast


Let’s talk JavaScript

with us anymore, which is fine.


Let’s talk JavaScript

We don't need him to record a podcast.


Let’s talk JavaScript

This also gives me an opportunity to be more direct with Martin.


Let’s talk JavaScript

Welcome to our new Search Off the Record episode, which is going to be with just Martin and


Let’s talk JavaScript

me.


Let’s talk JavaScript

Say hi, Martin.


Let’s talk JavaScript

Uh-oh.


Let’s talk JavaScript

Hi, everyone.


Let’s talk JavaScript

I'm scared.


Let’s talk JavaScript

How are you all doing?


Let’s talk JavaScript

Yeah, you should be scared.


Let’s talk JavaScript

I have a very fascinating topic for today.


Let’s talk JavaScript

I heard or noticed that you like JavaScript.


Let’s talk JavaScript

Oh, here we go.


Let’s talk JavaScript

OK, yeah, sure.


Let’s talk JavaScript

And I don't know if you noticed, but I don't particularly like JavaScript.


Let’s talk JavaScript

That's the understatement of the year, but yeah, I may have noticed, yeah.


Let’s talk JavaScript

So I will want to convince you that JavaScript sucks.


Let’s talk JavaScript

OK, interesting.


Let’s talk JavaScript

I will try to convince you that it doesn't suck.


Let’s talk JavaScript

OK.


Let’s talk JavaScript

So how about we start with the beginnings?


Let’s talk JavaScript

Like, maybe how JavaScript started and why it started and then how it evolved and how


Let’s talk JavaScript

we started using JavaScript.


Let’s talk JavaScript

Because I was using JavaScript, I'm not just making stuff up about how I don't like it.


Let’s talk JavaScript

I did actually use JavaScript, and I know why I don't like it.


Let’s talk JavaScript

So you used JavaScript, but you decided that you don't like it.


Let’s talk JavaScript

I mean, you like C++, don't you?


Let’s talk JavaScript

Yes.


Let’s talk JavaScript

Yeah, OK.


Let’s talk JavaScript

Interesting.


Let’s talk JavaScript

So you like pain and miserability and, you know.


Let’s talk JavaScript

I like control.


Let’s talk JavaScript

I like it when things are predictive.


Let’s talk JavaScript

No, it's not predictive.


Let’s talk JavaScript

No, wait, wait.


Let’s talk JavaScript

That's wrong.


Let’s talk JavaScript

I like it when things are predictable.


Let’s talk JavaScript

I know if I write, for example, a variable, then I like to know what it will be even five


Let’s talk JavaScript

lines down in the code.


Let’s talk JavaScript

JavaScript I can't actually expect, but we are getting ahead of ourselves.


Let’s talk JavaScript

I don't actually remember how JavaScript started.


Let’s talk JavaScript

I think it came around 94, 95 from Netscape, maybe?


Let’s talk JavaScript

Yeah, it was Netscape.


Let’s talk JavaScript

Famously, it was, I think, designed within a week or something by Brendan Eich for Netscape.


Let’s talk JavaScript

Which explains a lot of things.


Let’s talk JavaScript

I mean, you know, creating an entire programming language in a week is a challenge to see.


Let’s talk JavaScript

To say the least.


Let’s talk JavaScript

So yeah.


Let’s talk JavaScript

And I think originally it was a server-side language called Mokao or something, if I remember


Let’s talk JavaScript

correctly.


Let’s talk JavaScript

So going back to your point, arguably, if the two of us sat down, we could probably


Let’s talk JavaScript

create a programming language in a week.


Let’s talk JavaScript

That's not to say that it would be amazing and it would have problems, but we could do


Let’s talk JavaScript

it.


Let’s talk JavaScript

Yeah, I would agree.


Let’s talk JavaScript

You can create a programming language in a week as demonstrated by JavaScript, which


Let’s talk JavaScript

has gained a lot of popularity.


Let’s talk JavaScript

Thank you for feeding my point.


Let’s talk JavaScript

So yeah, it started in 95.


Let’s talk JavaScript

It ended up in Netscape.


Let’s talk JavaScript

And if I remember correctly, back then I was using internet for other things.


Let’s talk JavaScript

Okay.


Let’s talk JavaScript

Were you a teenager?


Let’s talk JavaScript

Because then I think I have an idea.


Let’s talk JavaScript

I was using it for games.


Let’s talk JavaScript

Oh, yeah.


Let’s talk JavaScript

Games and music.


Let’s talk JavaScript

That's what I thought it was.


Let’s talk JavaScript

No?


Let’s talk JavaScript

I was playing chess.


Let’s talk JavaScript

My first thing with JavaScript was through chess.


Let’s talk JavaScript

Wait, what?


Let’s talk JavaScript

So I was playing chess online with an air quote AI or against an AI.


Let’s talk JavaScript

And that was made with JavaScript, at least the UI.


Let’s talk JavaScript

I don't know what the background.


Let’s talk JavaScript

Oh, interesting.


Let’s talk JavaScript

Really?


Let’s talk JavaScript

Because I would have expected in the 90s to have seen that as like a Java applet or


Let’s talk JavaScript

something.


Let’s talk JavaScript

So maybe it was Java applet.


Let’s talk JavaScript

What's the difference between JavaScript and Java applet?


Let’s talk JavaScript

Right.


Let’s talk JavaScript

So when JavaScript came to the browser first, it was called LiveScript.


Let’s talk JavaScript

And then I think Sun was on board as well.


Let’s talk JavaScript

And Java was a really, really popular thing back in the day.


Let’s talk JavaScript

So Java is still around.


Let’s talk JavaScript

It's mostly used in the back end these days.


Let’s talk JavaScript

It's a statically typed language.


Let’s talk JavaScript

You compile the language into a machine readable code, and then you have what's called a virtual


Let’s talk JavaScript

machine to execute that machine readable code.


Let’s talk JavaScript

So JavaScript usually ships in human readable form.


Let’s talk JavaScript

Java usually ships in machine readable and not human readable form.


Let’s talk JavaScript

And Java, as far as the browser is concerned, is a black box.


Let’s talk JavaScript

So you have this black box as part of the page.


Let’s talk JavaScript

So there's the page, the HTML, with all the things that the browser can actually interact


Let’s talk JavaScript

with.


Let’s talk JavaScript

And then there's this black box.


Let’s talk JavaScript

You can imagine it as a window inside a window or an iframe, if you're more inclined, where


Let’s talk JavaScript

the browser doesn't know what's going on inside this rectangle.


Let’s talk JavaScript

And in this rectangle, there's a Java virtual machine that actually executes the Java code.


Let’s talk JavaScript

And so what happens when a website had a Java applet is that you would load the HTML, the


Let’s talk JavaScript

browser would deal with the HTML, would load the CSS, would deal with the CSS, and then


Let’s talk JavaScript

it would basically hand over control to Java, which is installed on the device that you


Let’s talk JavaScript

are working with.


Let’s talk JavaScript

In the 90s, that's very likely your desktop computer, maybe a laptop if you were fancy


Let’s talk JavaScript

at the time.


Let’s talk JavaScript

And then this Java runtime that you have installed on your computer actually takes care of executing


Let’s talk JavaScript

whatever is inside this black box.


Let’s talk JavaScript

That has upsides and downsides, obviously, because you're basically handing out control


Let’s talk JavaScript

from the browser so the browser doesn't know what's going on anymore.


Let’s talk JavaScript

You have to have this Java client installed on your computer to actually execute it so


Let’s talk JavaScript

not everyone experiences that the same way.


Let’s talk JavaScript

So yeah, that has not gone so well, especially when mobile came around.


Let’s talk JavaScript

Not many mobile phones are actually running Java applets in websites, or not many mobile


Let’s talk JavaScript

browsers run Java applets, which is ironic because Java was also very, very popular in


Let’s talk JavaScript

the earlier quote unquote smartphones.


Let’s talk JavaScript

If you had like a Sony Ericsson K700i or something like that, they were having Java runtimes


Let’s talk JavaScript

installed, the so-called Java 2 mobile environment, or J2ME for short.


Let’s talk JavaScript

So you could build Java code that ran on these phones, but not in the browser.


Let’s talk JavaScript

It was quote unquote a native app in that case.


Let’s talk JavaScript

So they are slightly different.


Let’s talk JavaScript

That's what you are saying?


Let’s talk JavaScript

Yeah, slightly very much different.


Let’s talk JavaScript

OK, so maybe I was playing on a Java game, not the JavaScript game.


Let’s talk JavaScript

Doesn't matter.


Let’s talk JavaScript

It was used, and I'm asking you, for similar things though, right?


Let’s talk JavaScript

Like blinking the page and blinking the text and other smaller UI elements.


Let’s talk JavaScript

Do you remember when you came to some person's website and your mouse cursor was followed


Let’s talk JavaScript

by some text like, hello, welcome to my website.


Let’s talk JavaScript

And they're like, oh my god, what's happening here?


Let’s talk JavaScript

I think I had that on my Myspace page.


Let’s talk JavaScript

I had that on some of my websites as well.


Let’s talk JavaScript

And also snowflakes whenever it was winter and it started snowing on websites.


Let’s talk JavaScript

We should bring that back.


Let’s talk JavaScript

I think that was awesome.


Let’s talk JavaScript

We should put it on Google, like on the home page.


Let’s talk JavaScript

Oh my god, that would be awesome.


Let’s talk JavaScript

Was JavaScript actually designed for these simpler things?


Let’s talk JavaScript

I think it was mainly designed to add some amount of interaction to the websites.


Let’s talk JavaScript

Because beforehand with HTML, the maximum level of interaction that you had is you can


Let’s talk JavaScript

scroll a page and you can submit a form.


Let’s talk JavaScript

But also forms were meant to be originally designed to just, you fill it out, you click


Let’s talk JavaScript

a Submit button, and then it sends the form data over with a request to the server.


Let’s talk JavaScript

And then the server responds with a new page with some sort of result to it.


Let’s talk JavaScript

So it wasn't really designed for much more complex things like games or other stuff.


Let’s talk JavaScript

It was more designed to, oh, I want to have a button that if I click on it, it does something.


Let’s talk JavaScript

And then the page content changes.


Let’s talk JavaScript

That's more like, oh, I have a Show and Hide button.


Let’s talk JavaScript

If I click on this button, then something is shown that hasn't been shown before.


Let’s talk JavaScript

That might actually explain a lot.


Let’s talk JavaScript

Some of the grievances that I have with JavaScript seem to stem, again, I'm not a JavaScript


Let’s talk JavaScript

expert because, well, I hate JavaScript.


Let’s talk JavaScript

But the few things that really annoy me seem to stem from the fact that it was not meant


Let’s talk JavaScript

to do more complex things, at least not in the beginning.


Let’s talk JavaScript

And for historical reasons, some of the things still stuck around because we can't just break


Let’s talk JavaScript

the web.


Let’s talk JavaScript

Right.


Let’s talk JavaScript

But in all honesty, I think JavaScript did manage to achieve a few good things.


Let’s talk JavaScript

Like for example, I remember I always only ever had a Windows computer.


Let’s talk JavaScript

I only very briefly had Linux personal computer.


Let’s talk JavaScript

So stuff like ActiveX, for example, was on my computer.


Let’s talk JavaScript

And sometimes we had to use that while we, as in Gary and I, had to use it for random


Let’s talk JavaScript

weird things.


Let’s talk JavaScript

And it was kind of annoying for various reasons.


Let’s talk JavaScript

Like for example, the packages that sometimes you were missing and then you had to figure


Let’s talk JavaScript

out how to download it on your 14 kilobyte modem.


Let’s talk JavaScript

That was pain.


Let’s talk JavaScript

And downloading like 800 kilobytes worth of ActiveX packages was a pain.


Let’s talk JavaScript

So yeah, JavaScript seems to have gotten rid of those things, at least.


Let’s talk JavaScript

That is true.


Let’s talk JavaScript

And also you see less Java applets on the internet.


Let’s talk JavaScript

And that's probably also thanks to JavaScript.


Let’s talk JavaScript

And Java applets used to be huge.


Let’s talk JavaScript

And you can accomplish most of the things with a lot less JavaScript.


Let’s talk JavaScript

I'm not saying that most developers do, but you can.


Let’s talk JavaScript

Right.


Let’s talk JavaScript

But going back to the previous point that JavaScript was meant to be a simpler language,


Let’s talk JavaScript

we do much more advanced stuff with JavaScript nowadays.


Let’s talk JavaScript

Like the single page apps, for example, they are almost completely done with JavaScript.


Let’s talk JavaScript

How are we doing it with JavaScript if the language itself was not meant to create those


Let’s talk JavaScript

experiences?


Let’s talk JavaScript

So to understand why and how, I would say we need to look into the early 2000s, mid-2000s,


Let’s talk JavaScript

because there was a bit of stagnation on the web.


Let’s talk JavaScript

And that varied and annoyed a bunch of people.


Let’s talk JavaScript

Because the W3C has decided to look more into XHTML, which is an XML-based HTML dialect,


Let’s talk JavaScript

and hasn't really invested in moving the web platform forward like everyone else might


Let’s talk JavaScript

have wanted to do.


Let’s talk JavaScript

That's why the WhatWG was founded.


Let’s talk JavaScript

So basically, a bunch of people were like, huh, there's a bunch of things that we now


Let’s talk JavaScript

have in applications that we kind of expect to have on the web as well.


Let’s talk JavaScript

And we have no way of having that, because there's no forward motion on HTML4.


Let’s talk JavaScript

We don't really see progress for HTML5.


Let’s talk JavaScript

So we want to do some stuff that we can't do in web, but we can do in native applications.


Let’s talk JavaScript

For instance, it's not magical bananas things.


Let’s talk JavaScript

It's things like tabs.


Let’s talk JavaScript

If you use any program, there's a very big likelihood that in some window of that program,


Let’s talk JavaScript

be it in the settings or I don't know, somewhere else, you may end up in your browser.


Let’s talk JavaScript

It has tabs.


Let’s talk JavaScript

You have a tab bar where you have different things, different documents, different websites


Let’s talk JavaScript

next to each other.


Let’s talk JavaScript

You can navigate between them by switching between the different tabs.


Let’s talk JavaScript

So your program can allow you to work on more stuff at the same time or have multiple streams


Let’s talk JavaScript

of work at the same time.


Let’s talk JavaScript

If you were to present information that way on a website, you simply didn't have anything.


Let’s talk JavaScript

There was nothing that allowed you to do it.


Let’s talk JavaScript

Optimally, you would expect that there's like a tab box HTML element or something where


Let’s talk JavaScript

you can build exactly this kind of interface.


Let’s talk JavaScript

Or accordions where you have like a header and then you click on that header and then


Let’s talk JavaScript

a section expands.


Let’s talk JavaScript

We didn't have that.


Let’s talk JavaScript

None of that existed.


Let’s talk JavaScript

So people were like, we want this kind of stuff, but we can't have this kind of stuff.


Let’s talk JavaScript

So how could we get this kind of things anyway?


Let’s talk JavaScript

And JavaScript turned out because it allows us to manipulate the document.


Let’s talk JavaScript

It allows us to respond to user input like clicks and drags and whatnot to actually have


Let’s talk JavaScript

this drag and drop interactions didn't exist.


Let’s talk JavaScript

You can't drag and drop HTML elements around the page as a user and then have things happen.


Let’s talk JavaScript

So people were becoming very, very creative and basically faking these things on the web


Let’s talk JavaScript

by using JavaScript and CSS in very, very, very creative ways actually.


Let’s talk JavaScript

So here, yeah, I've once built because I once had to use different computers across different


Let’s talk JavaScript

locations.


Let’s talk JavaScript

And I was like, remote desktop is a pain.


Let’s talk JavaScript

Also because I was using three different operating systems at the time between these 10 different


Let’s talk JavaScript

machines that I was working on.


Let’s talk JavaScript

So I built myself a fake operating system kind of thing.


Let’s talk JavaScript

So I had an interface where I could create like Windows and I had different applications


Let’s talk JavaScript

and it all ran in the browser thanks to JavaScript.


Let’s talk JavaScript

It wasn't fantastic.


Let’s talk JavaScript

But for simple things, it got the freaking job done.


Let’s talk JavaScript

The backend was written in PHP.


Let’s talk JavaScript

It was bananas.


Let’s talk JavaScript

Like I could send emails, I could read my emails, I could take notes.


Let’s talk JavaScript

And it all worked on every device that had a browser.


Let’s talk JavaScript

And I'm not saying it was great.


Let’s talk JavaScript

It was heavily abusing JavaScript as a language.


Let’s talk JavaScript

It was such a dirty piece of code just because the language was never intended to be used


Let’s talk JavaScript

for such a kind of application.


Let’s talk JavaScript

And this creativity has penetrated the web for the first decade of the 2000s, I would


Let’s talk JavaScript

say.


Let’s talk JavaScript

And then the mobile apps came and smartphones became a thing.


Let’s talk JavaScript

And people wanted the web to feel more appy.


Let’s talk JavaScript

And it doesn't really feel like an app if you are, I don't know, putting in your username


Let’s talk JavaScript

and password.


Let’s talk JavaScript

And then the page goes blank for a couple of seconds until the server sends back the


Let’s talk JavaScript

first page after login.


Let’s talk JavaScript

And that feels like the 90s web that doesn't feel like the 2010s web apps or apps to begin


Let’s talk JavaScript

with, like mobile apps to begin with.


Let’s talk JavaScript

So people were using JavaScript in a pattern called Ajax, a synchronous JavaScript and


Let’s talk JavaScript

XML, where you would click the button.


Let’s talk JavaScript

But the form wasn't actually sent the typical way.


Let’s talk JavaScript

But JavaScript kicked in and took the information, sent it to the server in the background, maybe


Let’s talk JavaScript

showing you like a little loading bar or a spinner or something.


Let’s talk JavaScript

And then when the data came back, JavaScript was used to update the page content so that


Let’s talk JavaScript

it would do the same thing as it did before.


Let’s talk JavaScript

So this feature was available.


Let’s talk JavaScript

It just didn't feel and look so good.


Let’s talk JavaScript

And I don't, as a developer, I don't have control over this page becoming blank and


Let’s talk JavaScript

then coming back with content, period.


Let’s talk JavaScript

But I do have power to control this and power to shape the experience when I do that with


Let’s talk JavaScript

JavaScript.


Let’s talk JavaScript

Was that great?


Let’s talk JavaScript

Not necessarily, because if there's a mistake in my JavaScript, the form stops working.


Let’s talk JavaScript

And then I can't log in and everything becomes terrible.


Let’s talk JavaScript

Whereas with a form that uses a server, there is not that much that I as a developer can


Let’s talk JavaScript

do wrong in the front end, because I just have the form in HTML.


Let’s talk JavaScript

As long as that displays roughly correctly, the server will take care of the rest.


Let’s talk JavaScript

And as long as my server code is roughly OK, I'll get some response back and it'll be fine.


Let’s talk JavaScript

We invented the wheel sometimes.


Let’s talk JavaScript

And this somehow has stuck.


Let’s talk JavaScript

So now the web has a lot more power and lots more cool stuff that it can do without JavaScript.


Let’s talk JavaScript

But lots of the techniques from that era stuck around.


Let’s talk JavaScript

And one really good indicator for that is jQuery.


Let’s talk JavaScript

Oh, yeah.


Let’s talk JavaScript

I don't know if you remember when jQuery came around and what it tried to do.


Let’s talk JavaScript

So what I remember is that when I created one of my first websites, then the example


Let’s talk JavaScript

that you brought up, the tabs on the page, I was using JavaScript to do the switcher,


Let’s talk JavaScript

basically hiding and revealing elements through manipulating CSS through JavaScript.


Let’s talk JavaScript

I was OK with the result.


Let’s talk JavaScript

It looked OK, and I managed to style it in a way that it felt more natural, because that


Let’s talk JavaScript

was one of the things that we wanted to do to make it look more natural, more intuitive.


Let’s talk JavaScript

That's a tab, and you can tap it.


Let’s talk JavaScript

Or not tap it, sorry.


Let’s talk JavaScript

That's way too Gen X to click it, because you were on a desktop computer, most likely.


Let’s talk JavaScript

Yeah, JavaScript was great for that.


Let’s talk JavaScript

But then we evolved the web.


Let’s talk JavaScript

I wanted to do more stuff with it.


Let’s talk JavaScript

For example, when I had the image hosting service, and again, one of the examples that


Let’s talk JavaScript

you brought up, form submission, when someone was uploading a picture, I didn't want them


Let’s talk JavaScript

to see a blank page while they are waiting for the upload.


Let’s talk JavaScript

I wanted to show them pictures of cats, for example.


Let’s talk JavaScript

And achieving that with server side code is just not possible, also not with HTML.


Let’s talk JavaScript

What you could do is maybe have a listener and refresh the page every now and then, but


Let’s talk JavaScript

you still have to have the listener on the client side.


Let’s talk JavaScript

And it's horrible.


Let’s talk JavaScript

The code just looks terrible then.


Let’s talk JavaScript

And then we started to get solutions for this.


Let’s talk JavaScript

And one of the first solutions was jQuery.


Let’s talk JavaScript

And it was fantastic.


Let’s talk JavaScript

It was one of the best things that ever happened to me on the internet when I found jQuery.


Let’s talk JavaScript

Because suddenly, I had access to all the DOM elements on the page without any voodoo


Let’s talk JavaScript

or black magic or weird castings.


Let’s talk JavaScript

And I could manipulate them however I wanted.


Let’s talk JavaScript

It had a few built-in solutions for accordions and tabs and whatever.


Let’s talk JavaScript

But you could invent your own UI element if you so wanted to.


Let’s talk JavaScript

You could have balls that were falling from the sky, and people could click those balls


Let’s talk JavaScript

and reveal new menu items if that's what you wanted.


Let’s talk JavaScript

And that was brilliant.


Let’s talk JavaScript

That was one of those moments where I felt that, yes, finally I can do something with


Let’s talk JavaScript

JavaScript without wanting to kill myself.


Let’s talk JavaScript

MARTIN SPLITT


Let’s talk JavaScript

It was the difference of, yes, sure, I can give you a bunch of materials, and then you


Let’s talk JavaScript

build your car from steel and rubber and copper wires and I don't know what.


Let’s talk JavaScript

Or I give you a car.


Let’s talk JavaScript

If you're really into building the car, giving you the raw ingredients and having you build


Let’s talk JavaScript

the car yourself from parts is probably amazing.


Let’s talk JavaScript

But if you just really quickly need to move a couch from one part of Zurich to the other


Let’s talk JavaScript

part of Zurich...


Let’s talk JavaScript

GARY I call Martin.


Let’s talk JavaScript

MARTIN SPLITT Yeah, for instance, yeah, you call Martin


Let’s talk JavaScript

because Martin just comes with a car.


Let’s talk JavaScript

That's easier that way.


Let’s talk JavaScript

GARY So I don't need a car.


Let’s talk JavaScript

MARTIN SPLITT You don't need a car.


Let’s talk JavaScript

You just need a Martin.


Let’s talk JavaScript

GARY Yeah.


Let’s talk JavaScript

MARTIN SPLITT This feels very Rick and Morty to me somehow.


Let’s talk JavaScript

Morty, let's go on a quick adventure.


Let’s talk JavaScript

I don't know, Rick, I don't know.


Let’s talk JavaScript

I have school today.


Let’s talk JavaScript

It's going to be really quick, in and out, 15 minutes.


Let’s talk JavaScript

Come on.


Let’s talk JavaScript

Let's do it, Morty.


Let’s talk JavaScript

Oh, man, Rick, I don't know.


Let’s talk JavaScript

GARY Okay.


Let’s talk JavaScript

That was surprisingly great.


Let’s talk JavaScript

Do it more.


Let’s talk JavaScript

But one thing that didn't happen was solving the low level issues of JavaScript.


Let’s talk JavaScript

And those grievances are still there.


Let’s talk JavaScript

And I prepared a list.


Let’s talk JavaScript

MARTIN SPLITT Oh, my goodness.


Let’s talk JavaScript

GARY Just for you, because I knew that you would love it.


Let’s talk JavaScript

And I only want to make you happy.


Let’s talk JavaScript

MARTIN SPLITT Okay.


Let’s talk JavaScript

Before we jump into that list, let me say one thing also.


Let’s talk JavaScript

So jQuery was amazing because it gave us a higher level.


Let’s talk JavaScript

It also was amazing because it gave us compatibility between the different browsers, like the jQuery


Let’s talk JavaScript

functions worked on every browser that it supported.


Let’s talk JavaScript

But nowadays, yeah, mostly.


Let’s talk JavaScript

I remember having to write like 100 lines of code just to make things work in Internet


Let’s talk JavaScript

Explorer, as well as Netscape, as well as Opera.


Let’s talk JavaScript

Now you needed to write like five lines.


Let’s talk JavaScript

GARY Yeah.


Let’s talk JavaScript

And then you had a message on the bottom of the page saying that this only works on Internet


Let’s talk JavaScript

Explorer 7.


Let’s talk JavaScript

MARTIN SPLITT True.


Let’s talk JavaScript

Yeah.


Let’s talk JavaScript

Mm-hmm.


Let’s talk JavaScript

GARY That was great.


Let’s talk JavaScript

MARTIN SPLITT It was lovely, wasn't it?


Let’s talk JavaScript

GARY It was the best solution ever.


Let’s talk JavaScript

MARTIN SPLITT But these days, most of the compatibility layer functions of jQuery just


Let’s talk JavaScript

add weight.


Let’s talk JavaScript

And actually, the browsers have solved, like modern browsers have solved most of the problems


Let’s talk JavaScript

that jQuery sets out to solve.


Let’s talk JavaScript

So jQuery might not always be the best choice for modern web development.


Let’s talk JavaScript

GARY Okay.


Let’s talk JavaScript

Before I jump in, what are some of the modern jQuery replacements?


Let’s talk JavaScript

I know of you.


Let’s talk JavaScript

Like for example, I think I know of you.


Let’s talk JavaScript

Like Node.js, that would be something.


Let’s talk JavaScript

MARTIN SPLITT Ooh, now we're entering very different territory.


Let’s talk JavaScript

Keep going.


Let’s talk JavaScript

What else?


Let’s talk JavaScript

GARY And I know Angular.


Let’s talk JavaScript

Mm-hmm.


Let’s talk JavaScript

And that's it.


Let’s talk JavaScript

MARTIN SPLITT Okay.


Let’s talk JavaScript

So JavaScript has grown in popularity and has also moved back to the server, interestingly


Let’s talk JavaScript

enough.


Let’s talk JavaScript

So Node.js is not really a replacement for jQuery because Node.js does not run in the


Let’s talk JavaScript

browser.


Let’s talk JavaScript

It runs on the server.


Let’s talk JavaScript

So it allows you to use JavaScript on the server, which is a thing you can do.


Let’s talk JavaScript

GARY But why?


Let’s talk JavaScript

MARTIN SPLITT Well, because why not?


Let’s talk JavaScript

You know the answer.


Let’s talk JavaScript

GARY No, that's never a good question, why not?


Let’s talk JavaScript

In that case, let me answer your why question with because.


Let’s talk JavaScript

Is that an acceptable answer?


Let’s talk JavaScript

GARY Oh, yeah.


Let’s talk JavaScript

That's much better.


Let’s talk JavaScript

MARTIN SPLITT That's much better.


Let’s talk JavaScript

So Node.js actually runs on a bunch of microcontrollers, for instance, so you can even program robots


Let’s talk JavaScript

with it or boats and stuff.


Let’s talk JavaScript

I've seen a lot of weird things being built with Node.js.


Let’s talk JavaScript

You can.


Let’s talk JavaScript

You don't have to, obviously.


Let’s talk JavaScript

I know.


Let’s talk JavaScript

Before you give me a look of like, why would you do that, let me reiterate my answer of


Let’s talk JavaScript

because.


Let’s talk JavaScript

I actually once programmed a drone that I would program using Node.js.


Let’s talk JavaScript

That was fun.


Let’s talk JavaScript

To add to your enjoyment of this, it crashed like 10 seconds later.


Let’s talk JavaScript

GARY Good.


Let’s talk JavaScript

MARTIN SPLITT Yeah, good.


Let’s talk JavaScript

Okay.


Let’s talk JavaScript

GARY How about Angular?


Let’s talk JavaScript

MARTIN SPLITT Yes.


Let’s talk JavaScript

And then there's like a bunch of frameworks that help you build web apps and build web


Let’s talk JavaScript

apps faster than if you would use vanilla JavaScript.


Let’s talk JavaScript

So a lot of the compatibility stuff that was introduced in jQuery, for instance, the way


Let’s talk JavaScript

that you address an element that is now actually native in the web.


Let’s talk JavaScript

So like pretty much all browsers have document.querySelector, which is one of the prime features of the


Let’s talk JavaScript

world of jQuery.


Let’s talk JavaScript

And then there's like Angular and React and Vue.js and all the other frameworks that are


Let’s talk JavaScript

out there.


Let’s talk JavaScript

They provide you with an ecosystem of best practices and tooling and libraries and resources


Let’s talk JavaScript

to do things that you will often do in web applications.


Let’s talk JavaScript

So for instance, if you need to draw a menu, you know, like one of these little hamburger


Let’s talk JavaScript

icons that on desktop is just there.


Let’s talk JavaScript

It's a menu on the side or on the top.


Let’s talk JavaScript

On mobile, you would want it like hidden away behind the button.


Let’s talk JavaScript

If you press that button, the menu comes in.


Let’s talk JavaScript

It just has that.


Let’s talk JavaScript

It just allows you to do that with like a couple of lines of code instead of having


Let’s talk JavaScript

to like code all the logic for it in hundreds of lines of code.


Let’s talk JavaScript

GARY So it's abstracting.


Let’s talk JavaScript

MARTIN SPLITT It's abstracting things away.


Let’s talk JavaScript

Exactly.


Let’s talk JavaScript

It also gives you like ways of structuring your code and your application into modules


Let’s talk JavaScript

or components so that beforehand you would basically just have like a gigantic file of


Let’s talk JavaScript

JavaScript with lots of functions in and it was like spaghetti code.


Let’s talk JavaScript

You had no idea where which part of the code would be going.


Let’s talk JavaScript

Then people were splitting that out into individual functions and modules.


Let’s talk JavaScript

And the frameworks just give you additional ways of like stowing away and abstracting


Let’s talk JavaScript

away your own code as much as they also give you predefined abstractions that you can use


Let’s talk JavaScript

as building blocks for your web applications.