Delivering WordPress in 7KB

Over the past six months, I’ve become increasingly interested in the topic of web sustainability. The carbon footprint of the Internet was not something I used to give much thought to, which is surprising considering my interest in environmental issues and the fact that my profession is web-based.

The web in a warming world

As a brief recap, I attended MozFest in London last year. In between sessions I was scanning a noticeboard to see what was coming up, and I spotted a session entitled “Building a Planet-Friendly Web”. I felt a little dumbstruck. What on Earth was this going to be about?

I attended the session, and the scales fell from my eyes. In what now seems obvious but at the time was a revelation, I learnt of the colossal energy demand of the Internet. That this demand makes it the largest coal-fired machine on Earth, meaning that its CO₂ emissions are probably at least equivalent to global air travel. More and more people are coming online, but this coupled with the rise of ever more obese websites means that the Internet’s energy demands are growing exponentially. Every additional byte transferred means more energy, which in most countries means more CO₂.

It is widely accepted that we should avoid printing emails to save trees, but this leads to a false assumption that the web is a green medium. I’m afraid to say, it is not.

Another way?

The good news is, it needn’t be this way. Since 2009, Greenpeace have been auditing Internet companies on their energy usage, and lobbying them to improve by way of their Clicking Clean campaign. The Green Web Foundation has an ever-growing database of hosting companies who use renewable energy, or are at least committed to being carbon neutral. And new tools are emerging to help those working on the web measure the environmental impact of our products.

There are also some great resources out there such as Tim Frick’s Designing for Sustainability, three year’s worth of talks from the SustainableUX conference, and peripheral material that while not explicitly focused on sustainability, can help us build lower carbon websites.

Enter Susty WP

I decided to challenge myself to see how efficiently I could package a WordPress website. While I was at it I thought, why not make the website about sustainability and WordPress? I know, WordPress/sustainability inception. Cool, huh?

And so, is born. With its accompanying theme, Susty. I’m rather chuffed to say I managed to get the load of the homepage down to 7KB of data transfer. I did actually get it down to 6, but the meta stuff added by Yoast bumped it up almost a whole KB! 😛 However, given I’m trying to spread a message, I deemed this to be an acceptable trade-off.

Before I get into the nuts and bolts, I just want to share a few headline facts:

So how does it work?

Note: From this point on, this post gets a little technical. If you’ve come upon it and aren’t a web developer/software engineer type, feel free to skip to the conclusion.

The remarkable thing about this is actually how mundane it is. Heavily inspired by Heydon Pickering’s evangelising about writing less damn code, and projects like Brad Frost’s Death to Bullshit, I embarked on a root and branch pruning of Underscores, removing everything I possibly could. And to be clear, it’s not as though Underscores is full of cruft. It’s a very lean starting point for building a theme. I’m a great admirer of it and thoroughly endorse its use. However it includes certain assumptions that didn’t chime with my spartan goal of making the smallest possible WordPress site. Such as, you ask?

Nav? No. Sidebar? Get rid of it. Classes? Not in my socialist utopia.

Given the constraints I had set, anything making it to the DOM had to have a very good reason to be there. With this being an experiment, I took the somewhat radical approach of relegating the navigation to its own page. This is wonderfully liberating and means I didn’t have to go through the almost always disappointing dance of wondering how I would make it look presentable, hide it for the many users who won’t care, make sure it’s robust enough to be infinitely long with never-ending dropdowns etc.

This means less HTML, less CSS, and definitely no JavaScript! Win, win, win.

As for the sidebar? Well I’ve always had an aversion to sidebars, so that was an easy thing to remove. Susty has no widget area. I’m sure it’ll get over it.

Is there more fat we can trim? Well, if we’re going to have hardly any HTML, and we want minimal CSS, do we really need all those classes? I wanted to try my hand at writing CSS in the way it was intended to be used, instead of bowing to the classitis and divitis that pervade the industry.

You might not need web fonts

Alongside images, video and JavaScript, the other item that has become a significant factor in what bloats websites is web fonts. Given that it’s now a Silicon Valley fashion for every startup to commission its own typeface as a first order of business, it seems as though every website you visit incurs the downloading of a bunch of font files. It may not seem so bad to tack on a hundred kilobytes for some nice type, but when you multiply this by the many different people visiting your website across different devices and browsers, fonts can easily account for hundreds of megabytes of data transfer. If not gigabytes/terabytes/petabytes for higher traffic websites.

Custom web fonts are also a potential antipattern for our users, for whom:

  1. Page loads are slowed down as they see either a flash of unstyled text or, potentially even worse, no text while the font loads.
  2. By the time the font has loaded, they don’t notice or care.

Almost every device these days has a half-decent set of fonts installed, so why not compose a stack of potential fonts you’d like to see, ending with either serif or sans-serif.

I wanted Susty to have a bit of a Swiss Style aesthetic, so my font stack ranges from the perfectly proportioned Helvetica (which all Apple devices have by default) to sans-serif, by way of Arial, Frutiger and Nimbus Sans L.

As an Ubuntu user, I see Arial, which is perfectly pleasant. On my Android devices I see the default sans-serif font (Droid Sans I believe), which actually works rather well on mobile — you’d almost think that’s what it was designed for!

What else? Standard stuff. Few/no images, SVGs if anything

Beyond this, it’s really just the standard. The homepage of has no images and just one SVG which is loaded inline rather than by an http request. The CSS is minified. Everything gets Gzipped. The server is tuned with NGINX and Fast-CGI cache to serve content from memory.

Bonus SPA-like features without the work or code

When I was boring my girlfriend Daisy with my plans, I asked her how she felt conceptually about a website not having a navigation, and it instead being on its own page, found via a “menu” button. She thought it sounded ok. So when I came to show it to her, I watched eagerly as she clicked “menu”. Her response was that she didn’t really think about clicking to see the menu, and the menu appearing, as changing pages. This confirmed one of my fears that my previous obsession with eliminating page loads when building Single Page Apps (SPAs) is something that only really bothers web developery types. Most people don’t really notice it or think about it. So if you make your website lightning fast, the page loads themselves are almost imperceptible anyway.

With that being the case, I figured why not just pretend it was a menu overlay? So I added a cross dismiss button and a tiny bit of JavaScript to take you from the menu back to the previous page if you click it. (I did initially implement this in PHP using the $_SERVER superglobal and HTTP_REFERER, but this breaks when using something like FastCGI cache to serve pages. I.e. for those pages there is no $_SERVER superglobal.)


  • Finish reading Jeremy Keith’s book Going Offline so I can implement a Service Worker and make Susty even more performant.
  • Look to see how I can implement Gutenberg. It’s going to add a bunch of kilobytes and that makes me sad! 😉
  • Currently, is hosted in one data centre in London, and served globally from that location. This means that someone in Wellington, New Zealand for example is not going to get the full experience! I have a longer term plan of establishing my own little CDN of edge servers (each one hosted by a 100% renewable energy powered host in each location that I can find one) just running NGINX and serving cached versions of the site. This is a simplified way of how we do things on VIP.

In conclusion

Susty is an example of taking sustainable design techniques to an extreme. I’m not suggesting that we should all start building websites with this exact method. But I do think sustainability should be a much higher priority in the web design industry. It’s good to think about saving any kilobytes we can, and to think in terms of kilobytes rather than megabytes. If you do want to use a JavaScript interface library, why not try out Choo.js, which has React-like features and comes in at just 4KB. Remember, NASA managed to put a man on the moon with about 50KB of data storage to play with.

The best thing about all this is that efficient websites means faster websites, which means:

  • Happier users
  • Better search engine placement
  • Happier servers

Featured photograph: “Susty WP” by me is licensed under CC BY 4.0

83 replies on “Delivering WordPress in 7KB”

Thanks Rachel! I would urge a little caution to anyone using it – it hasn’t been thoroughly road-tested yet. I’m not using it here for example, though I’m planning to use it or a slightly modified version. And yep, I’ve been hosting a few different things with Kualo for the past couple of months and the experience so far has been great.

Nice writeup and a lot of interesting ideas in there. Thank you for sharing!

somewhat radical approach of relegating the navigation to its own page

I personally find this idea the most interesting, but also am not sure about it’s benefits.

I guess it really depends on the specific use-case, but in case the menu is something visitors are actively using, then every trip to menu and back generates two ~3.1KB “big” requests done over the network. One to the menu page and either back to the current one (“closing” the menu), or to some other page.

That said, unless the menu implementation would be bigger than 3KB, it would, imho, had been better if the menu was part of the original page. On the other hand, in case the site running the theme would have a huge bounce rate, it would be better if the menu was not part of the site.

Out of curiosity, do you have any stats on the total number of visits to the /menu endpoint on the ?

The ~3.1KB mentioned above is for HTML obtained from the nginx, as the CSS is stored by browser in disk-cache and served from there. Which leads me to another idea.

I have noticed that there are no Cache-Control headers being sent for standard page view, nor for the /menu endpoint.

Thus, every time I open the menu, new request to the origin is issues. In case the theme would send even just Cache-Control: public, max-age=3600 header when serving /menu, browsers would serve the next visit to the menu from disk-cache.

In case you were able to figure out, by collecting some stats, how much time average user spends on /menu, the Cache-Control headers with some acceptable timeout could even be sent along with standard page requests, so the menu closing operation would be served from the disk as well.

Thank you for the comment David!

So you raise a very interesting point here. Unfortunately in an effort to to make the site has quick to load as possible – and to avoid any GDPR implications – there’s no tracking at all… Which is possibly an oversight!

However, I think we can make some general assumptions that the menu is likely to get a fair amount of usage. I agree that at least having a Cache-Control header would probably be a good idea for the /menu endpoint.

Another technology that I’ve been tinkering with is the preload, prefetch, and prerender link relation types. In particular, the latter one would allow the menu to be prerendered for users before they even click on it. However the browser support for this isn’t great yet:

I ended up long-grassing my tinkering in this vein because I think the optimal way to manage all this will be through a Service Worker, which is a technology that I’ve been tinkering with for a couple of years now but haven’t done much experimenting with in the wild.

A Service Worker can give very granular control over interactions and the browser can receive updates when content is updated. So for the most part I imagine the /menu endpoint could be cached at the Service Worker level and allow the website to check periodically whether or not that content has changed.

Leaving out any kind of fancy tracking is considered an “Oversight”? No, I dont think so. I’ve been intentionally avoiding that waste of time and space for years, if not decades. If you are NOT running a shop or site that directly sells any kind of goods to customers, you dont need the excessive “warfare” of Google Analytics, Piwik and so on. Yes, with a commercial site you definitely wand and also need to know at what point and why people do abort getting your stuff, but not with a regular one, like a portfolio, or your personal blog.

So, IF I want to know how my clients found out about me, I just ask them. Most of the time they tell me this during our first talk or mail dialogue,so even that is mostly superfluous 🙂

cu, w0lf.

Hmm, this is very curious. It’s also a bit funny because I checked the site and received good results with so many tools, but hadn’t come across this one.

This tool doesn’t appear very representative of reality. Most browsers provide at least some diagnostics on TTFB, and having tested the site in a lot of different ones (with cleared caches etc.), I’ve never seen a TTFB as high as this tool is reporting.


That’s right. Good catch.

Google’s Home page can’t pass it’s own recommendation of a 200-millisecond TTFB any more. Why? Because of SSL certification. That’s on a simple page with one silly search field. Ridiculous Google hypocrisy. They make the rules and they break them.

See what happens for Google Home page on their own idiot speed test, PageSpeed Insights:

The Google Home page gets an orange/yellow code for mobile failure (not green). This is the fastest, most expensive server on the Internet?

RESULTS (and #1 optimization recommendation):

== Reduce server response time ==

[ In our test, your server responded in 1.4 seconds. There are many factors that can slow down your server response time. Please read our recommendations to learn how you can monitor and measure where your server is spending the most time. ]

Google’s own reference page linking from that result says:

[ This rule triggers when PageSpeed Insights detects that your server response time is above 200 ms. ]

NOTE: Part of the reason that Google TTFB is 1.4 seconds is because if you don’t enter https:// in the address there is a redirect delay. A flaw in the test. But even if you do add it, will fail their own test. Normally their TTFB is around 400 to 500 milliseconds. Still doubly too slow.

So let’s go to another Google-owned test to double check:

TTFB: 457 ms
Primed-cache Load time: 1.754 seconds
Fully loaded: 3.662 seconds

We see the real “payload” is much bigger and longer for that simple page than it’s ever been. Why? Google’s own SSL edict slowed the page. Is it good enough speed? Yeah. It’s under 2 seconds. But one second is the new ideal. BECAUSE OF SLOW REMOTE MOBILE CONNECTIONS.

Fortunately, Google doesn’t use their results in the new Mobile-First Ranking algorithm. They only use one speed parameter.

What is that speed parameter?

TTFB (time to first byte) that is all.

Your theme is the fastest free theme I’ve ever tested. But silly SSL ruins the gains. All your hard work negated.

Speed is about UX. There’s no speed benefit for SEO. And I specialize in mobile speed.

I do agree the ByteCheck tool gives a worst-case TTFB scenario. It’s one of the few tools that reveals how hard sites are really hit by dogmatic SSL certification. Typically 400 to 500 millisecond loss.

Without TTFB drag from SSL, I’m testing your theme on a shared GoDaddy cheap mechanical server. The load time is about 500 millisecond (no images, repeat-visit). If I was to add SSL/HTTPS on GoDaddy for $69 per year (a ridiculous speed tax), the load time would double to 1 second.

Thanks for making me think.


PS- I love what you’ve done. I’m writing a speed theme performance review on PagePipe of SustyWP today.

PSS- I can’t believe you’re using Jetpack plugin on this very blog post about speed! Tell me, “Why?”

Thanks! I’m using Jetpack for uptime monitoring, brute force login protection and VaultPress backups. I’m not using any of its front-end modules.

Hi Jack,

Great post and nice initiative! I agree that we should be much more conscious about making websites with a smaller impact. We’re trying to optimise load time, but simply making them smaller and cleaner will get us far.

I think that your site is great as a basis for more complex and larger sites, much like _s. All additional features should be done with progressive enhancement. Maybe you’re familiar with the contest 10k apart: A few years ago, a cool idea from A List Apart to encourage web designers to go back to basics, ditch frameworks, …

Also, thanks for the resources on sustainability.

Thank you Csaba!

Yes, I’d like to flesh this area out with some more themes that aren’t quite as spartan as Susty!

And yes, part of my inspiration for doing this was the 10k Apart contest. I’d love to see them revive that and run it again.

Hi Jack,

Wow, Susty WP is very cool! And that is one ultra speedy site/theme.

Have you come across the GeneratePress theme? Its creator, Tom Usborne, also likes things lean and mean. (I’ve been using GP and its premium option a lot lately for projects.)

For fun, I put up a bare bones, out of the box, WP install running the free version of GeneratePress to see how it close it was to Susty WP! (that’s on my staging/development domain – which also lives on Kualo’s hosting!)

It’s loading at 15kb – so over double the size of Susty WP but still pretty good 😉

Thanks for your hard work on this and raising the awareness of web resources and sustainability. The more low resource things for the web, the better! 🙂

Interesting! I think you can reduce the size and number of requests by put all CSS inline. As your CSS is small, inline them reduces 1 requests and thus, can improve the speed. I’ve done this simple trick for my website ( and it reduces the loading time to almost 1 second, which is huge.

Inlining small CSS files is a best practice recommended by Google.

[ If the external CSS resources are small, you can insert those directly into the HTML document, which is called inlining. Inlining small CSS in this way allows the browser to proceed with rendering the page. ]

Do I trust Google as an authority about speed. Not much. But at least this practice is recognized as a viable alternative.

I agree with it.

On a side note: This reminds me of my own site, although the intention behind it was a different one; in my case, I wanted to test out and play around with existing, current browser technology, trying to stay away from feature and library overload like jQuery + Co.

Instead, Vanilla JS, pure HTML 5 + CSS, no need for webfonts (aside of Font / Fork Awesome), and also no fancy CMS .. just a plain HTML file, some CSS, which is powered by a bit of JS (either handwritten or found on, just one simple PHP router and my personal small form mailer, which has been around for quite some time, and been improved tremediously over the course of the last 13 years 🙂

Thus, no cookie orgy, no excessive data sniffing issues, and so on. Thus also my GDPR compliance comment goes like this: This site uses NO cookies – it never did and also never needed to! Apache creates the usual activity log, but nothing else. … and so on 🙂

Nowadays I think a reduced CMS toolkit should rather suffice for powering ones personal site, and esp. one which is up for any kind of sustainability.

cu, w0lf.

This is an awesome little project. Its great to see what you can do when you strip it down to bare bones. But now you need to add things in I think. Id be curious to see what sustywp would function if it was a full blog with google analytics and a comment engine. I do not think that would add a ton of weight. But maybe?

Hi, i really like this theme and the concept itself. I am doing some test trying to put more minimalism (and maybe faster??) where:
– I delete the header black border
– Delete the icon and “Susty WP” text, accesin Home from the menu (as URL),
– Delete the “Menu” H1 text.
– Change “Menu” for the typical “hamburguer” icon (3 horizontal lines)
– Changing all backgrounds to white.

Best regards,

Hi, thanks for your comment. Yes, it’s true to say one could still trim the site down a bit more. You can go a step further than what you’ve suggested and get rid of the CSS altogether. Then the site would be served in 3-4KB.

I wanted to keep a degree of design, so I’m happy to sacrifice a few bytes for the border, title text, icon and off-white background.

Personally I really don’t like the hamburger icon and feel it poses an accessibility issue as not everyone knows what it means. Also wouldn’t an SVG of a hamburger menu actually take up more bytes than just text saying “menu”.

Is this question aimed at me or the original commenter? I’d say the hamburger icon represents the language of web developers.

“Menu” can be easily translated. Though I realise I should make that into a translatable string.

Good post though, I hadn’t considered a unicode option for a hamburger icon. But I still don’t like them! 😉

This is an eye-opening post, especially for WordPress developers like myself. One question before diving into the theme: It seems to be planet-friendly, but what about human-friendly? What is the current A11y status of the theme?

Once again, congratulations for paving the way to a more eco-friendly web and raising awareness.

As a side note, it seems to me that if people stopped watching porn, then about 30% of Internet-based carbon emissions would be eliminated.

Thank you!

I’ve retained all of the core accessibility features of Underscores, so I think it’s reasonably good on that front. The homepage scores 100/100 for accessibility with Google’s Lighthouse auditing.

Haha, and yes you make a good point about porn. However I think trying to stop people watching porn is a much harder task than just making the websites themselves more efficient. Though there is an economic theory that suggests increased efficiency will also lead to more usage!

So the real answer is shifting more of the web onto renewable energy so the carbon emissions are lower regardless of efficiency. 🙂


I’m using Susty on a website. Everything is working nicely. Load time to US destinations are around 500 milliseconds. And to Europe and Australia about 1 second. No CDN. Cheap GoDaddy shared mechanical server. Worst-case load time on is also 1 second.

Very nice.

I only have one problem and perhaps you can advise a solution. We’re using a background non-scrolling non-tiling image. It loads globally at full-screen width which is working fine. Except on the Menu page. Then it’s not looking so good. Any explanation or a fix? Here’s the URL so you can take a peek:

Thanks for creating this theme.


Hi Steve, this really had me scratching my head, but I’ve worked it out.

The problem here is that the background is set to fit the size of the content. Unfortunately this means that the image only grows to fit the length of the content. That is to say that if you make the menu long enough, it’ll look the same as the other pages. This is related to the CSS properties that WordPress is applying behind-the-scenes.

Unfortunately, it looks as though the custom background controls provided by WordPress don’t give you an immediate fix for a problem like this. And just having to make your menu longer isn’t a great solution! However you can fix it with a few lines of “Additional CSS” in the customiser:

.custom-background {
background-size: 100% auto !important;

This tells the browser that the width of the background image should always be 100% of the width of the body, and that vertically it should scale proportionately.



Brilliant! Thanks for the fix.

I’ve got your CSS installed and everything looks great. I’m doing another post about why small (lightweight) themes are important. Susty is the case study with this site as an example of speed possibilities using severe limitations.

The bottom line is: stripped themes – like Susty – prevent excessive bloat. It’s a “human temptation” problem – not a design problem. Site creators can’t discipline themselves to say “no” to unused features. They fill every slot provided. Self-imposed limitations using a bare-bones theme removes overload or gold-plate seduction.

You can’t overburden widgets that aren’t there!

That’s the unadvertised value of minimal feature sets in lightweight themes like yours. Instant self-control.

As a side note, we’ll document the plugins and other speed tricks keeping this case study fast. But here’s a suggestion pertinent to your comment about adding CSS code:

“Additonal CSS” code often (usually?) disappears when changing themes and sometimes when updating. It depends upon the theme author’s diligence. Preservation isn’t built into core as one might suppose.

If you add a child theme to preserve custom CSS code from accidental overwriting during any update, you’ll generate an extra HTTP request. Our workaround (and there are others) is to use Tom Usbourne’s free “Simple CSS” plugin. It appears alongside the normal Additional CSS feature in the WordPress customizer. This plugin doesn’t create an extra call (like a child theme) but still protects the code.

Thanks again for such a beautiful theme example. Lots of love coming from PagePipe.


Jack. My chin is on the floor.

Following on from this a friend of mine pointed me here:

and, even though the data that they post might not be 100% accurate, I’m dumbfounded that I am producing so much carbon each. I could literally not have imagined that it would be this much.

I think that this is a subject that needs to be discussed a whole lot more, and if you’re willing, I’d love to have you on my podcast:

to discuss this some more with you and our listeners.

Thanks for making me know about this.

If you really want to reduce demand on the server and the amount you send across the internet, ditch WordPress. Use a static site. Static site generators make it easy for anyone, eg starting with markdown instead of html.

If you don’t want to do that, I imagine there are alternative CMSs with a smaller footprint than WP.

Talking about wordpress: Many websites use WP for static sites, but WP comes with lots of features that are only needed by blogs. Would it not be a good idea to have a wordpress-version that strips off all of that stuff if it is not used? Maybe that will save energy and loadingtime aswell.

Hi Jack,
your article on WP and sustainibility does not goe out of my mind. I have some ideas on that topic and will answer you later on my own blog. I would like to join you with that topic, how can I get into contact with you? I did not find any imprint on your site. Here is my contact: maybe you can send me your email.

But nevertheless I will drop some lines already here. I can only speak about my typical clients which are – more or less – freelancers, artists, small companies etc. etc.
– The clients decide what designers like me build.
– The clients (at least most of them) do not have any idea about the techniques designers or develloper use.
– But they have whishes: They want their websites done cheaply, fast and good looking. That brings a great preassure into the industry, designers are more or less forced to use readymade themes (premiumthemes) which have lots of disadvantages like slow loading and tons of loaded code. But adapting a premiumtheme is much cheaper than coding yout own theme.
– And (that is often important) clients want to have the possibilty of managing the content without any knowledge of HTML odr CSS.

– If you tell them, that a handcrafted theme e.g. based on Automattics underscore-theme costs (lets say) the double of adapting a premium-theme like Divi AND that the handcoded theme will not offer them a reale easy possibility of managing the content, they will choose the premiumtheme.

A real gamechanger could be, if there were a industry-standard displaying the CO2-emission of every theme. Or a scale where each theme has e sustainibillity-score. In that case arguing would be much easier. I could tell my clients: OK, if you use premiumtheme XY that will produce 5g of CO2 every-time the website is shown in the browser. But if I code the theme myself, it will only produce 0,5g everytime. (The numbers about CO2 are very imaginativ, to be honest I do not have any idea at this moment, how much CO2 a theme produces.)

So the main point is: How is it possible to introduce that scale to the industry? Because only then clients can compare the different products.

Hi Raphael,

I was also thinking about some kind of grading that could be shown on about the CO2 footprint of a theme. But there should be some standard content to enable that. A website using theme could weigh much more with some badly compressed images in the content and some additional plugins…

It could also be included in a speedtest like google insights. Or an additional test could be offered. Maybe Automattic wants to offer such a test. I am no devellopper, but I think, that it cannot be very, very complicated to build such a machine.

If such a test shows the CO2-consumption of any tested website and gives a number such as 4g of CO2 or 0,2g of CO2 that would make people think much more. And it would offer a lot off opportunities for designers/ develloppers to have such a number.

I think if that works for you, that’s great. I think trying to convince about a third of the Internet to stop using WordPress will be more difficult than trying to make WordPress more efficient! 😛

I would also say that if the server is probably configured and caching is set up properly, WordPress and PHP work together very efficiently. When PHP is idling it causes the server to use very little additional energy.

The problem is not wordpress. The problem is that most of my clients want to use 1001 plugins, want to upload images with the size of the Empire State Building, they want to have everything done in a way that even a intelligent monkey can work as admin, they want to have music on their websites, they want to have videos and all kind of crap like facebook and so on.

AND: They want it all for free with ready-made plugins ant themes such as Divi. 😉 THAT is the real problem.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.