web analytics

Home of my tech rants, free programs, and a story or two…

DSLReports, you are dead to me…

I talked some time ago about how I stepped away from DSLReports, I went back to the site after a month of not visiting it and kept going to it for some time until I once again got into it with the moderators over what was essentially very stupid stuff.

I don’t agree with a lot of the community and this is where I got into it with the moderators on several occasions which usually involved my posts being removed with no way to repeal the decision, or at least the moderators gave me the idea that they didn’t give a crap. They didn’t even care about the fact that I’ve been there for over ten years, I donated to the site and otherwise was considered to be an MVP. No, it appears that if you didn’t toe the site’s company line and agree with the community at large, the moderators tended to act like jackbooted thugs.

I’ve since moved to TechPowerUP and in the two years there I’ve not gained the ire of the moderators. Well OK… I did once but that was it and I’ve not had any run-ins with the moderators since. They tend to apply a rather light touch when it comes to moderating at TechPowerUP whereas at DSLReports it often felt like you were having Thor’s Hammer from the Marvel movies come down on your head. Sure, there are times when the moderators have had to step in but they usually let threads progress without any intervening unless of course things got really out of hand.

Oh… and they’re not nearly as politically one-sided at TechPowerUP. I’m participating in two threads in the lounge forum and I’ve on multiple occasions expressed political opinions that make me appear to lean to the right, this very act alone on DSLReports would have had me banned for a week (or more) simply by leaning right. If you didn’t get the idea that DSLReports is run by a bunch of leftists, you weren’t reading my post.

So yes, DSLReports… you are dead to me. I won’t be coming back. You lost a long-time member and I don’t care.

The issues with the Healthcare.gov web site

The thoughts of having to get health care is on the minds of millions of Americans at this time of the year and for Ohioans, this means having to go to the Healthcare.gov web site. Many people have experienced issues with using the Healthcare.gov web site. These issues include filling out forms and getting random errors to the web site simply not loading even in the most basic form. But, it doesn’t have to be that way.

Myself, I have been around computer for years and have worked to develop a web site that had a lot of traffic. I worked as a help desk technician for a web hosting provider in my past and worked to help optimize the community forums for a well-known open source web development software known as Joomla. With that being said, I know how to develop an optimized web front end for web sites that need to handle a lot of traffic in an optimized way.

I have personally looked “under the hood” of the Healthcare.gov web site using the built-in developer tools of Google Chrome. I conducted an audit of Healthcare.gov using those development tools and found that many of the frontend components (images, Javascript, CSS) that make up the web site are not using web known web site optimization techniques such as compression and web browser caching.

Compression allows for things like Javascript and CSS files which are mainly simple text files to take less bandwidth or space “on the wire” to send to the user. Web browser caching allows for often used components that make up a web site to be cached on the user’s computer as versus having to go back to the web site to re-download them every time the user clicks to go to the next web page or part of the web site’s many user fillable forms.

Sadly, many of the components that make up the Healthcare.gov web site are not using these well-known web site optimization techniques and thus putting far more stress on the frontend web servers than is needed to be. Caching the content on the user’s computer in the web browser’s disk cache could reduce the load on the Healthcare.gov web site by nearly half. Half may not seem like much but when you’re talking about millions of page loads per second from all over the United States it can go a long way to helping the site perform faster with less load on the backend servers that power the web site and that means a faster web site and less issues and frustration for the user trying to sign up for healthcare.