Using Scribe for ALL text... Bad?

I’ve got into a potentially bad habit of using Scribe for pretty much all text content on the page; headers, short text sections, long text, a mixture of headers and body text, etc.

I realise some of those scenarios are exactly what Scribe is made for, but I’m wondering if in some instances, like when I just want a header, I shouldn’t use Scribe as the default?

It’s at the point now really where the only time I’d use a header stack (Header Pro being the default) is when I want to do some unusual to the header, or have different sizes on different screens, etc.

My concern though, using Scribe for almost everything, is that I may be adding way more code to the page for a simple header- Not saying Scribe is code heavy, i suspect it’s not, but my assumption is it’s got more code than a header stack?

Anyway, views and opinions (and hard facts) welcome.

Ta.

1 Like

I think it’s the other way round, Scribe with multiple headers and paragraphs in one stack will be a lot smaller (code wise) than individual header and para stacks.
I’d guess that a Scribe with just a header in it would be identical or possibly slightly smaller than a stock header stack code wise.

I think I’m right in saying that even SEO isn’t a problem as the #’d header code in Markdown gets rendered as regular html header code during publish.

1 Like

Ya, I get that a Scribe is smaller and better than a header and lots of para stacks, but your last comment I think covered my poorly word question: Is using Scribe just for headers bad?

Ta.

1 Like

Try this:

Add a 1 col stack to a blank page and insert a standard stack header. Copy and paste the header 9 times and then do the same for the 1 col so that you end up with 100 header stacks.

Now create another new blank page and do the same but use 100 Scribes containing just the same header text. Now compare for page load and preview and preview in Safari.

I have not tried this but I’m pretty certain what you will find.

1 Like

My guess would be that scribe produces less code on the page than header pro

The basic stacks header will be least but then again it does not even have alignment controls.

All scribes functionality comes from the built in markdown processor in RW edit mode and so has no effect on the amount of code output - it renders HTML in edit mode.

All you are adding is a bit of css. The actual HTML will be cleaner than a header stack.

Whichever, Ithink you can consider it white noise compares to the size of other non text elements on a page

2 Likes

And here are the results from the Scribe jury.

Per page (shared between all Scribes on the page) - 4kB
Per Scribe stack: 620 bytes

59

1 Like

Understand what you say about the non text elements, but that’s reality, I tend not to worry too much about reality, just the small things in my mind ;-)

Thanks for the comments though folks. I shall carry on as before. I prefer using Scribe over any other text stack now so it’s all good.

2 Likes

Scribe is quick in Edit and preview mode too. In my example test there is not that much Edit and Preview times between the stacks header and Scribe but there is a noticeable difference when using the Foundation Header which of course also needs SiteStyles and Foundation so is definitely not an apples to apples.

My recent focus has been to ignore server page times but to focus on using the minimum edit mode footprint stack where possible. So often the Stacks Paragraph stack is perfect when you just need left aligned default text. My old strategy was always to use the most powerful stacks on the expectation I could later edit to use a feature already in the settings. The reality was that things just slowed down too much and I rarely used the power of those full powerful stacks.

2 Likes