Hacker News new | ask | show | jobs
by sajidnizami 5565 days ago
I too work with sites hitting high visitor count but I have to agree there with the article. Most .Net people I've interviewed think page load speed doesn't matter. They write code to satisfy the requirement and are quite good at it, but it ends there.

Remember when people used ASP.Net web forms and it was hard to get rid of viewstate in the rendered page, and only the people who knew internals of platform well could fix it. It drove SEO's mad and they started to recommend staying away from web forms.

I agree with you on the staging and testing servers. Not having them is planning for disaster.

5 comments

I too work with sites hitting high visitor count but I have to agree there with the article. Most .Net people I've interviewed think page load speed doesn't matter.

I find this shocking and somewhat unbelievable. My wife, who isn't a tech person at all thinks that page load speed matters (she just called so I asked her) -- and sites gmail as an example of a page that takes too long to load (I think that "loading..." indicator actually brings their load time to the forefront, although it really isn't that long).

I just have trouble seeing a .NET developer saying "for high volume sites page load speed doesn't matter", when most people who aren't in the tech industry would concede that it does.

It does but I think you misunderstood the point.

Most .Net developers are working on intranet sites. They don't have problem with large footprint pages.

When they move to internet and public domain websites, they are newbies. It takes them a while to adjust to the way internet sites are written. SEO optimizations, CDN usage, Ajax calls etc are pretty important on internet site than on intranet site.

Imagine using a Update Panel to code for an internet website. It would create enough junk javascript to delay a page load but it works fine on intranet. To fix this jQuery or some other Javascript framework must be brought in.

Well, that's why if you're looking for a business model, here's something that works -- take intranet applications people commonly use and release alternatives that do not suck so much.

Companies like 37signals are doing it successfully ;)

The way you said it originally made it sound more like they simply don't think it matters. I think what you really mean is what you said here. They are newbies when dealing with high volume sites where page load time is critical.

IMO, that's a very different statement. One is a difference in experience with a domain, the other is ideological.

I don't think they mean like that. If something is obviously slow its a problem regardless. However, especially when you have a certain number of users, even a fraction of a second faster load time can have a visible change in your analytics.

I've read before that Facebook has shown that users tend to spend a fixed amount of time on their site. Once users hit that time limit, they're done. If your site exhibits similar usage patterns, the faster your pages load (even if they're already fast), the more users can get done on your site, which, depending upon your revenue model, may result in more revenue.

That information about fixed time usage is interesting. But even with that aside, doesn't everyone know that fraction of a second decreases in load time is important for high volume sites?

For example, MySpace was getting at one point 24 billion page views per month. If you could reduce each page view by 1/100th of a second you save 40 weeks per month for your users (assuming the model where they look at a fixed number of pages).

In the Facebook model, if you assume a page comes up in half a second, this delay results in a 2% decrease in page views -- which is a pretty huge deal when your business model indirectly revolves around page views.

I guess my point is that even for people who come from a background where page load didn't matter. it would take 30s to point out it does, and I don't think you'd get any pushback.

* you save 40 weeks per month for your users*

that sounds big and important, but it doesnt really mean much does it?

the difference between a 1/100th of a second and 2/100th's of a second is too small to translate to enough time to get any increase in productivity.

There must be someother reason that load time is that crucial.

It's not so much that certain programmers don't think that page load speed matters; it's that the culture around the platform doesn't encourage speed.

You're conditioned to not care anymore, because ASP.NET Web Forms makes it so damn hard to achieve responsive web apps, and building responsive web apps almost universally means breaking away from the standard ASP.NET Web Forms style of development. You have to abandon pretty much everything that makes the platform convenient in order to get good performance.

Web forms were designed back somewhere around 2002 to compete with the likes of JSP etc. They still work well for their domain, which is intranet portal etc.

MVC however is designed from grounds up to deliver speed and web standards compatibility. Building for web these days with Web Forms is just wrong. But yes, most to actually bend Web Forms to deliver requires wizardry.

If your knowledge of ASP stops at webforms, then you have nothing to say about anything recent in ASP. It's all gone MVC and jQuery. StackOverflow is a good example.
You must be getting the shit end of candidates because I know as many brilliant C# developers as I do C, , PHP, Python etc. I also know plenty of terrible Ruby, Python etc. developers. You can not generalize based on the tool a developer uses based on you interviewing a handful of people

oh and that viewstate forms thing from SEO is the SEO talking bullshit and trying to justify his job

You are right about candidates.

I had the same reaction to SEO at first. See SEO guy is partially right. It involved page load times. Larger viewstate means longer load time and that gets penalized by Google.

Sure.. maybe it's harder to build a top-notch .NET team than a LAMP one... but I think the point is that you have to know what a top-notch team and set of processes look like in order to build them... on any platform. If anything the tech-choices are symptomatic of a bigger issue.
>Most .Net people I've interviewed think page load speed doesn't matter.

Have you informed them that you work with a high traffic site? Most intranet sites are not high traffic, so if they're spending time pre-optimizing for speed instead of features/development time, they're actually wasting the company's money.

And what has viewstate got to do with SEO? You lost me.

For SEO friendly URLs, all you need a is URL Rewriter. http://www.google.com/search?client=opera&rls=en&q=a...

>only the people who knew internals of platform well could fix it

That's true of any platform out there.

Something like this: http://stackoverflow.com/questions/1185984/is-viewstate-bad-...

Yes I talk to them that we have a high traffic site and we lose them because they don't know about building them. Besides you won't find many Microsoft stack sites dealing with scaling issues. I personally looked up Stackoverflow scaling case studies to design my solutions later.

Back in 2005/6 URL rewriting was still pretty difficult. I started out back then. I converted to MVC completely when 1.0 version came out specifically to address the SEO concerns.

But I guess our discussion is swinging to technical side :)

In ASP.NET 4.0 and MVC, URL routing is built-in, and it's easy as pie.
SEOs prefer to have the "relevant content" as high on the page as possible. Since viewstate is just a large blob, many SEOs assume it decreases relevancy. I've never seen results that confirm this assumption.

Edit: See sajidnizami's post for the relevant StackOverflow question. Though, this still doesn't make sense to me logically. Why would a search engine disregard a (reasonably) longer page?

Longer page would increase page load time. A longer page with viewstate at the beginning would delay loading of content. Google penalizes pages that load slower.

http://googlewebmastercentral.blogspot.com/2010/04/using-sit...