The dinosaurs will remember when people obsessed about Source-Ordered Content. In fact, it was enough of a concern that you could just say SOC and everyone knew what you meant.
Knocking Your SOCs Off For those who need a refresher, before CSS when people were building layouts with tables, you had no good option but to put the visual top of your page highest in your code. The search engines were dumb back then and they would commonly crawl only a small amount of your page and would often use the first bit they found as the snippet. If your code was confusing or your navigation was excessive, that was all the crawler saw.
When browser support for CSS reached a critical point, but search engines were still not chunking out repeated content and years from regular rendering with headless browsers, many SEOs used CSS to position the content first in the code and put the page header at the bottom. The idea was to feed the search engine first and foremost what was unique to the page.
Then off course, Google knocked our SOCs off. They introduced content chunking and headless browsers and were followed by other search engines and we all pretty much quit bothering.
Doing CRP When Your Site is in Render Arrest Now that the patient has had its SOCs knocked off, we went and gave it a very high fat diet - lots of JQuery and Bootstrap and a zillion other things. Next thing we noticed, it was going into rendering arrest. So we have to do CRP, not CPR, to save this patient.
The
Critical Rendering Path [developers.google.com] describes which objects have to load before the page can show the above-the-fold content. If you have a blocking resource, it means the whole page has to wait for that resource to load before rendering. This is bad and at least three years ago, Pierre Far was saying at Pubcon that SEOs should be paying more attention to the CRP.
What to do?
It's not nearly so simple as SOC, but unlike the SOC problem, it's also not going away because search engines get smarter. There are things you can do, however.
We are concerned above all with resources that block rendering above the fold. But in this world of many screen sizes, what is above the fold anyway? First priority should be resources above the mobile fold, because mobile users are more likely to be on slow, high-latency connections.
1. Identify those resources. Run Pagespeed Insights or GTMetrix or some other tool that will identify your render-blocking resources.
2. Start fixing the problem.
Fixing the CSS If you have render-blocking CSS, you can inline it. If you run Pagespeed on your server, it can do this for you on the fly. See
[
modpagespeed.com...]
You can also run a tool like CriticalCSS and see what it suggests for inlining. Note that this will lead to some bloat unless you also go through your CSS and remove the rules that you've now inlined.
[
jonassebastianohlsson.com...]
Fonts are a common culprit and for that you can use some web font loader like
Typekit's Web Font Loader [github.com]
Fixing the Javascript Easy, right?
There are several Javascript loaders. Some years back I got huge gains on a poorly-designed site with LABjs, taking a 12-second time to first interaction down to a 2-second time to first interaction (that is, when the page was visually present above the fold and ready to interact with, which is not the same as DOM-loaded or fully loaded). These days, I think RequireJS would be the most popular choice. But there are also conditional loaders such as yepnope.js and whole galaxy of tools.
They can help a lot, but some things simply can't be loaded asynch without breaking the site. For the site I mentioned above, I had to hide the main nav (you read that right, display:none on the main nav) until the document.ready event fired and then switch it to display:block after all the critical path components loaded. It made for a dramatically better user experience on first page load, but really it was a Band-Aid on a broken site that had been poorly architectured... and brand new.
Okay, so asynch won't work. Then we run Pagespeed and inline Javascript same as CSS, like so: [
modpagespeed.com...]
Done!
Not so fast (so to speak). Do you really want to inline tons of Javascript in such a way that it won't be reused on subsequent page loads. Remember: Reduce, Reuse, Recycle. Reduce comes first if possible.
Reuse/Recycle might include not just caching your files, but for the most popular resources (JQuery, Modernizr), loading them from a CDN to increase the chance they are already cached in the user's browser. Be warned, though, that if they are running an ad blocker or Privacy Badger, your JQuery from a third-party CDN might be blocked.
Add those into the mix with inlining and loading scripts asynchronously as often as possible and you're well along the way.
Your Experiences? Those are just a few half-baked thoughts thrown out as I type. More nuts and bolts than I had intended. I was really interested on a discussion at a bit higher level but, as is my tendency, got a little down in the weeds. Really, what I'd like to know is.
- Do you remember the days of SOC?
- Are you paying attention the CRP?
- What strategies have been most effective?
- What are the most common culprits? Which resources make up your Most Unwanted list?
