Details On How I Made My Blogger Website Load Faster Than Before
Introduction
Those who have been with Ghen Tech for quite a while know
that technology is not only the subject I write about but the subject I put to
practical test breaking it down, fixing it, and then sharing the details of how
exactly I went about it with you. This article fits into that "fixing my
blog by tearing it down" category.
This feeling of being slightly annoyed because the page is
opening slowly has been something I've been living with for a while now. Not
like the site was crashing or going down. It was simply... slow enough that
every now and then I caught myself waiting a second longer than I should have
for the header to show up, widgets to come steady, images to fade in.
If I could feel it as a site owner familiar with it, I had
to believe my readers especially those on mobile devices with limited data who
clicked on a search result were experiencing it even more than me. At length,
it hit me and I was able to do the thing that I really needed to do and that I
have been procrastinating on for so long: open my Blogger template's XML, stop
guessing, and actually measure what was making Ghen Tech blog sluggish.
There is a multi-day analysis process of redundant scripts,
obfuscated legacy code, dead widgets, the mistakes, and how to avoid them that
I have been making myself. It ended with my site being considerably more snappy
and I want to guide you step by step through my discoveries, what changes I
made and also how I was wrong a few times before doing it rightly.
Running a Blogger blog and have experienced that same
"feeling heavier than it should be" thing before? Then, this blog is
for you.
Why I Decided to Stop Putting It Off
To put it very clearly, I had been neglecting this issue for
quite a considerable amount of time. Blog templates, particularly those free
and even some premium ones you find online, tend to get all kinds of stuff
stuck on them. You install some kind of cool plugin-type widget to achieve an
effect you wanted long ago and forget to uninstall it when you don't need it
anymore, then there is this whole copy-paste "cool effect" script
from the tutorial you just blindly put in without even considering whether it should
remain, and soon your <head> and the bottom of the page are like little
graveyards of stuff nobody looks at anymore.
I didn't have one single "light bulb" moment that
drove me toward fixing it. It was an accumulation: a friend saying my site felt
lag on his phone, a little drop of my average session time on analytics which I
couldn't attribute to something else, and to be completely fair some remorse
from writing "how-to" technical content while applying that same
strictness to my own blog was beyond me. Therefore, I took a decision: I was
going to go through my blog template one line at a time, and I was not just
going to remove anything because it looked old, I was going to find out by
doing tests what was really working and what was just dead weight. I took the
below steps in performing the tests on my blog.
Step One: Actually Looking at the Code, Not Just the Symptoms
My starting point was to stop guessing and actually read the
blog HTML/XML source of my Blogger Theme via the Theme editor. To you, maybe
you've never used that, the fact that a Blogger template is basically a single
big XML file may be interesting to know. Your style sheet, your widget
definitions, your JavaScript every one of them is there one tag within another
tag, within another tag.
I went through it systematically, keeping an eye out
anything that I believed fell one of these areas:
- Duplicate
resources, the identical library or stylesheet used more than once.
- Orphaned
code, scripts or styles referencing elements that do not exist at the same
time.
- Unconditional
heavy widgets, loads on every single page view despite their relevancy
there or not.
- Stale
third-party integrations, external services getting older parameters or
expired versions.
I plan to go around each of these areas sharing my findings
and I think the majority, I mean, the ones especially which have been modified
or tweaked in over a year or two, would definitely show up just this kind of
issues as well.
The Duplicate Font Awesome Load
My first point was a Font Awesome load that I had in two
separate places and the one at the top I really had in my hands was an old
version from a single CDN and then, the properly placed, and indeed the one
inside my head, I was loading a completely different and new one from another
CDN.
Exactly the same icon set. All of the same font icons.
Two different files downloaded, two different
render-blocking stylesheets, essentially duplicating a thing that ideally would
have been just one single lightweight file to download.
In the end, I have a lot of guesses but no hard facts of how
long this issue had been around.
The most accurate estimate I have is that, sometime, I was
trying out a wrong icon in a wrong page, added a newly found font-awesome to a
different CSS, and once I have fixed the original problem through another
approach, the font-awesome link stayed there for no reason.
This is such a typical behavior once you add a bit of code
to debug something, it is fixed but you leave the snippet of code forever.
All I had to do was get rid of the older copy of the link
that was the duplicate one and let the newer one, the correctly-placed link, go
in <head>. Everything remains the same on the site but there is only one
Font family download now as oppose to two.
In case what you get is a summary of one thing from this
story, it should be a tip that, in case you are running a web site or a blog, open up the default layout file (usually called header.html or header.php) and
search the code for "font-awesome".
If the search reveals that the Font-Awesome link has been
called more than once, you definitely can save yourself time because every
browser renders CSS in sequence. So, it is better to leave one link and remove
all others.
Pagination Script Bug
At this point I have to speak truthfully and confess that I
think it was the key part in the entire case, especially for the technical part
of it.
In a corner of my template below the closing scripts, was a
piece of code that had been heavily obfuscated JavaScript that's got its code
packed and the variable names reduced to just one letter, the rest is just one
large string of characters. It was so unreadable.
My first reaction, upon seeing those lines of code, I
thought it was a relic of the old system. So I went ahead and searched for the
IDs which the script would be referencing and didn't find anything that even
somewhat resembled matches which led me to deduce that the code had been left
behind from an ancient pagination system whose only remaining reference was on
the page which now could no longer be seen.
So I got rid of it. For two whole weeks, I truly had a nice
feeling thinking that I had gotten rid of a considerable amount of unused code.
A reader (if by any chance you are that reader, please do
know that I am genuinely grateful, I mean it!) let me know that the numbered
page navigation at the lower portion of the homepage, the buttons with numbers
like "1 2 3 4 →", were actually no more.
Apart from a small thank me note for that, I was also really
taken back by that.
So with the help of a new reader, I actually did the
unpacking of that strange script rather than trying to figure its meaning just
by the names of the variables. When I finally had the real source of that
obfuscated code before my eyes, I was shocked the script was capable (and had
been) of working in two completely different ways. It would be possible to find
only one branch, and that is when there is no match for a particular attribute
in the page, a dead branch which misled me. However, the second option was
quite opposite through an element ID that definitely matched with my pager
container, it correctly targeted and produced the numbered pagination. That
second branch was exactly what allowed my numbered pagination UI to be visible
on the page!
I was deleting working functionalities because of
misunderstanding obfuscated code, without fully decoding it. It was a hard
lesson to learn, but I put things right as soon as possible.
Why I'm telling you this and choosing not to keep it secret:
because "remove unused code" is really good site speed advice. Unused
code still uses up parse resources and can sometimes be the cause of network
requests even though it doesn't display anything. But the key word here is
unused, and you can't determine that by a mere glance at the obfuscated code
and a guess. When something has been minified or packed so thoroughly that you
can't see it, don't rely totally on your first reaction. The wisest thing to do
in such a scenario would be first properly decode your script and run it through
The Dead Code I Actually Encountered
After thoroughly learning my lesson and deciding that I
should really understand the code properly instead of guessing at it, I went
back through the rest of the template much more carefully. I was quite
surprised that during this time, the only dead code that I found was the piece
which definitely was not in use (i.e., no guessing or uncertainty involved).
In fact, the block of obfuscated JavaScript that I found
this time turned out to be quite different from the first one that I found, but
at the same time similar in that I decoded and examined it very closely. It
turned out that this script actually mentioned element IDs and attributes which
had no reference elsewhere, not in my whole template. In fact, I have to say,
this was not a result of a misread branch or some kind of alternate path; it
was simply left unattended. So, either it was a remnant of some version of the
template or a former feature of the template which I had removed without having
cleaned up the script that was supporting this feature. Because I had verified
this rather than assumed it only I was quite sure that this one could be
removed.
Step Two: Making Changes That Have Nothing To Do With Speed, But Are Also Worth Doing
I was rolling up my sleeves to work with this thing and
found that there were a few things that were definitely not about load time per
se, but had been things I had allowed to remain unchanged and were now on my
list to fix. These changes were part of my bigger task of reorganizing things
at home or "getting my house in order" as it were.
An old Social integration
I was surprised that my Facebook page widget was inactive.
When the website loads, the widget is absent and there have been no signs of an
issue. After checking the issue, I found that my template's Facebook's SDK
script was pointed to a Graph API version of Facebook which had been already
deprecated and completely retired. Since Meta has been rolling cycles of new
API versions, mine had passed away completely without me noticing because that
kind of failure mode is very silent and does not show a visible error.
Changing the version number to a currently supported one
brought it back immediately. Although it is not a speed fix as such, these are
also exactly the kind of problems where "the website works technically but
a problem is quietly there" which accumulate if you do not periodically
audit your own template. Besides, a broken widget that keeps making a network
request for nothing is also a tiny speed tax of its own even while failing.
Rethinking How I Handle Third-Party Embeds
Giving this whole exercise some thought also helped me to
reconsider the bigger picture of how I interact with third-party widgets.
Previously, the widget I had of a Facebook Page and my
hard-coded YouTube video embed were unconditionally loaded on EVERY SINGLE PAGE
of my blog: each blog post, each archive page, each label page -- whether these
items had any relation to the content I was embedding or not.
I haven't taken out these features yet (after all, some of
them really help!), but now I'm quite more thoughtful to the extent that the
widgets would run on all pages or I should restrict the scope of their loading,
i.e., the widgets only appearing on my homepage or that they get loaded only
when somebody clicks. If you are doing the performance audit of your site, be
honest and ask yourself: is this widget really the one to come to all places,
or is it just because of my habit I never took the trouble of moving it from
one page to another that it got everywhere?
General Lessons Gained About Blogger Performance
Looking at the bigger picture, beyond my own template and
all the tweaks I was doing, the following is what would I recommend as the
strategy framework to any blogger doing what I did:...
1. Optimize Only After You Audit
Don't just start removing things because they look ancient
or out of date. Open up the console in your browser, then run a little bit of
network analysis (I personally find the Network tab really useful), to discover
exactly what is going on and how quickly. You may also choose to check
render-blocking resources, remove redundant CSS, or look out for multiple
libraries automatically done for you by using tools like Google PageSpeed
Insights or GTmetrix they would easily find the problem of duplicate Font Awesome
which was taking so much time in me to solve. It was not me but the problem;
and I would have spent less of 10 seconds there if I had just given Google
PageSpeed Insights a try instead of checking the raw XML visually.
2. Make a duplicate list first
You'll probably want to find and make a list of duplicate
resources. First, find out what resources are loading on your website by
looking for the names of icon libraries, JavaScript frameworks, or font
providers you use in your template. jQuery, Font Awesome, Google Fonts, such
the same resource as if loaded twice from different CDN URLs is quite a common
case because different people or different versions of yourself over time can
add it to the template.
3. Don't let the obfuscated code fool you
When you come across an unfamiliar minified or packed
JavaScript, don't just guess its function based on the meaningless variable
names.
In any case, make sure to run the code through a
"beautifier" or unpacker to see the real logic or, should you fear of
such thing, first block it out from the website using CSS and then monitor your
website for some time before removing it permanently. It was my very mistake,
in fact, as far as the pagination function was concerned; I just missed that
step altogether and relied on a fast check-over instead.
4. Think again what is loaded on every page
You shouldn't really worry, of course, that homepage or
post-specific embeds, widgets, and scripts have been loaded everywhere. Each
widget loaded unconditionally is an extra burden for users visiting those pages
where it brings nothing but burden.
5. Review the third-party integrations for obsolescence
Services get upgraded and replaced and their APIs are also
changed. A widget that was working perfectly when you set it up two years ago
probably has stopped being active and making no response although it is still
trying to reach out, so, from time to time, browse your own website the same
way any new user would do and verify that all items that could be expected to
be functional actually behave well.
6. Always create a backup before even touching the site live
This is how it happened to me once the live template had
changed, I had no way to go back and see the earlier versions of it. Prior to
making any modifications to the live template, you can download the current
template via Blogger's theme settings. If there is some problem or if, like me,
you later on that day find out that you mistakenly deleted something then
having a backup that brings you back to the last state will make it super easy.
What Was The Output?
Thanks to these changes, I was able to take out the really
unnecessary stuff, delete the duplicate Font Awesome reference, fix Facebook
integration, and in general, make sure only the most required features run
every time a page is rendered, the feel of Ghen Tech improved a lot. To me, it
felt more light or something.
The loading time seemed to be better as the final rendered page
appeared a bit quicker than before. The lag time where fonts change or icons
appear a bit later was significantly reduced.
I won't say that it was a great overnight miracle where
everything changed at once with data supporting it I was never going to run an
exact and thorough comparison of the before and now, a lesson which I have
learned later and which will be in my to-do list on my next pass of changes to
the site. But there was definitely a change in how it performed, as evidenced
from my own testing and also a couple of readers who mentioned that, they
didn't know that, it was just the first thought that came into their head when
they saw the new blog.
To me, the greatest lesson was the process part the one that
allows you to constantly ask the question, "is this still being used, or
are we just keeping around things that have served their purpose and are
forgotten already?" Instead of taking it on faith from template that if
something is there, then it has done a great job, the right approach was to
keep on checking if things are really serving a purpose.
What's Next for Ghen Tech
This has really sparked an interest in me, so I think that I
might get involved with more of the behind-the-scenes technical aspects that my
blog site relies on. One of these is doing a thorough performance speed
benchmark, comparing site speed before and after, as well as an audit of the
remaining third-party widgets for those of me which I am not actually using so
that they could be removed or at least their impact limited to some of the blog
pages. Frankly, I want to turn this kind of template review into a recurring
activity rather than a situation that I have to deal once every year or two
when the site has slowed down so much to finally provoke my reaction.
If you've been running your own Blogger site but the only
thing you've really done with your template is that you clicked on it from
within the Blogger UI, you should be more than happy to actually go through the
entire source code of your template just once. I guarantee you that there could
be some big surprises for you, especially in the form of things hiding there
quietly that are actually causing you slowdowns or at least they were ones that
you thought were the cause for your slowdown.
Apart from that, you still won't be sure without making an
inspection and I hope that this time you already know what to be looking for.
If you found this tutorial helpful or you have had one of those cleanup sessions yourself where you did quite a bit and even discovered a few nice optimizations, please drop a note on the blog comments I would especially be interested in hearing about those instances where you had one of these "duplicate Font Awesome" moments yourselves. I feel pretty much certain that I am not the only one carrying around quite a few of those.
0 Comments
Thank You For Your Comment on GHEN TECH