Improvement in Page Speed worth Compromise on HTML Validation?

[Kingalan1]

Our developer has improved page speed, particularly for Mobile. However the price for this improvement has been a HTML validation error that cannot be removed without compromising on the page load speed. Is the improvement in speed worth the living with the validation error? The concern is paying a high SEO price for this "fatal error". Or perhaps this error is in fact not serious?

1. Fatal Error: Cannot recover after last error. Any further errors will be ignored.

   From line 699, column 9; to line 699, column 319

   >↩ ↩

`OUR DEVELOPER'S COMMENT:

| This was made following Google page speed insights recommendations. If we remove that, will loose on page load performance |

The domain URL is www.nyc-officespace-leader.com`

[MoosaHemani]

I am not a developer so any developer with a SEO background can tell you better but in general page load speed is important both from user point of view as well as search engine rankings and as far as W3C validation is concern, there are quite a few errors that you can ignore in order to stick with your page load speed.

Hope this helps!

[Kingalan1]

Thanks so much. I understand most errors are not too important. However I wonder if a "fatal" error should not be of grater concern.

Thanks, Alan

[RiceMedia]

That error is coming up from the validator because the links to your stylesheets are outside the ending body and html tags. The stylesheet links normally go within the tags at the top but I understand from what you've said for page speed these have been moved to the bottom page however no tags / html / stylesheets / javascript etc  should be outside the ending and tags.

If you move the CSS stylesheet references and the comments so they are where the javascript files are (before the ending tags) that would fix the fatal error you are seeing.

Hope that helps!

[Kingalan1]

Would correcting the code in this manner so the html validates result in a slower page load timE?

[RiceMedia]

I'm not sure if it would affect the current page speed but it would fix the invalid HTML error from the validator. If the validation errors concern you it might be worth giving it a try and testing the result? It's good to make sure that pages validate all the high issues at least to be sure of no possible display or rendering issues in different browsers now or in the future.

[AlanBleiweiss]

1. Taking shortcuts that are not sound sustainable based methods to gain value somewhere else is almost certainly going to become a problem when you least expect it at some future date and this is a great example.  Moving CSS and or JS to below the proper location is a recipe for complete page display failure on any number of devices that may or may not current exist.

Have you tested your pages with Google's Fetch and Render to ensure they properly load, or where they may get a "partial" result? If they get a "partial" result, that's a red flag warning that you ignore at your own peril.

2. You haven't provided numbers - is the page speed improvement a case of going from 20 seconds to down to 5 seconds? Or is it going from 8 seconds to 6 seconds? Or what?  This matters when evaluating what to care about and expend resources on.

3. If just moving those to their proper place in the page header section is causing speeds to slow down dramatically, you have bigger problems. First one that comes to mind is "why do those scripts / CSS files cause so much speed slowdown? Its likely they're bloated and need to be reduced in size, or they're housed on a pathetic cloud server that is itself doing you more harm than good.

[Kingalan1]

Thanks for your excellent, highly detailed response!!

Is there a way to test the CSS files that my developer has created to see if they are coded in an efficient and concise manner?

We use a virtual private server at Inmotion Hosting and Amazon CDN for for images.  So I would think that the hosting service is adequate. Traffic does not exceed 3000 unique visitors a month so the load on the server is minimal.

[AlanBleiweiss]

Kingalan1

I'm not a programmer by trade - the way I begin even considering these things is by running tests on various tool platforms.

For example, put a page you think is slow into URIValet.com - test as Googlebot.  The resulting report has a block of information in it regarding total size of files processed.  It breaks that data down to file types.  Look at the CSS/JS lines - if they are more than 50k to 100k total for either CSS or JSS, there is almost certainly inefficiency in there, and likely unnecessary bloat.

Go to WebPageTest.org and do the same - put in the URL you want to check - choose a server location and DSL (which gives a fair mid-range speed evaluation), and Chrome as the browser emulator.  The resulting report gives you a lot of information, however the one page in that report that may be most helpful in this situation is the "Details" report - if you go there, and scroll down, you'll get to the section that lists, line by line, every single file, script, image and asset processed for that page, and all of the data on speed of processing each step of the way (such as First Byte Time, DNS lookup, SSL lookup, and more).  Those can reveal several individual bottleneck points.

[CleverPhD]

I agree with Alan's points.  I have also found WebSiteTest.com really useful.  It allows for multiple runs on multiple devices and you can download the results in CSV.  Expanding on Alan's point around looking at bottleneck points, when you use these tools, you need to take time to understand the waterfall chart as that is where you can see how the browsers interact with all of these files (html, css, js, images etc).

I have been doing a ton of reading on front end optimization recently.  Aside from all of the above, you could have issue with the critical rendering path (great resources here and here).  Many times folks look at a single asset and say, "This javascript file is too big, lets minify it and get faster!"  That is a good thing and will help you.  That said, you have to look at the render path as you may have that same smaller JS file blocking other downloads that need to be downloaded first to render the page faster.  Optimizing the render path can give you some additional gains.

Good luck!

[AlanBleiweiss]

Yeah sequence of load is also important when its time to go granular to find the true opportunities. Because the up-front evaluation time that can identify issues, can often result in faster-easier-more template-driven ways to speed up everything on a larger scale with less effort needed.

That doesn't mean its okay to ignore other bottlenecks.  Just that the more clarity of understanding, the more likely real, sustainable success can be achieved.