Separate Users Are Good

When you create a new domain on DreamHost, you can chose to make a ‘new’ user to ‘own’ the site, or use an existing one. There are pros and cons to both, but for anyone who comes from the cPanel world (where separate accounts are de rigueur), it’s pretty normal to expect your separate site to have a separate login name and password.

Explaining how all this works on DreamHost is a little different, because we have users and then we have users and … well let me explain.

There’s more than one kind of user

The first type of ‘user’ you have at DreamHost is your panel user. This user is the one you make when you sign up, and it’s usually your email. Don’t share this password with anyone, okay?

Next we have your ‘users’ which you can find in your panel. Those users are the ones who have access to things like ‘shell’ and ‘sftp’ and so on.

Then there are also those ‘other’ users you think of, like the login accounts on your blog, or your email, or maybe even the billing account for DreamHost.

When I talk about separate users, I’m only talking about the ones who have access to shell and stuff.

Users own sites

Those user accounts own sites. That means I have a specific user who ‘owns’ the folder on the server where all my web code lives. And you can see it’s that user because there it is, in the path: /home/USERID/domain.com/

Only one user can own, and access, a domain. However a user can own multiple domains.

So here’s what this looks likes. One user owning multiple domains:

one user multiple domains

And only one user can access the domain, user two cannot:

User 2 has no access

This is cool because if there’s a domain under User 2, and it gets hacked, there’s no way for User 1 to get hacked, even if both users are you![ref]Unless there’s a server wide security flaw, which yes, can happen, but we spend a lot of time trying to prevent that.[/ref]

Logical User/Domain Groups

If you own 50 domains (and I’ve seen users with 200!), having them all owned by one user sure seems easier, but it means if that user gets hacked, they’re all vulnerable, and you’ll probably end up having to de-hack 50 domains at the same time. Instead, it’s wiser to group your domains ‘logically.’ For example, my elftest.net domains have subdomains, all of which are owned by the same user. However my other top-level domains are each owned by their own user. But that doesn’t work for everyone.

Recently I was helping a customer with a hacked site, and he complained that the sites he hosted for his clients were being hacked, and his clients were pissed off. I took a look and saw that all his client sites were under one user ID. I asked him if the clients had more than one domain, or if they all had their own, and he replied that each client had 4 or 5 of the domains. After cleaning up the hack, together we made new user accounts, one for each client, and moved the domains to those accounts. If possible, I always clean before moving, but in one case the customer had 75+ hacked sites, so we moved and then cleaned each one, prioritizing the accounts on the way. It took a very long time.

109649_D_0989 The extra benefit to this is the clients can now have FTP access to their domains and do wild and crazy stuff! But we don’t want them to have FTP.

Moving The Domain

Obviously first you need to setup users. When I set up a new user, the first thing I do is make it secure. That means I turn off FTP, forcing SFTP only, and if needed, give them Shell access. Personally? I love shell access, so I always leave it available. If you’re using DreamPress, we have Shell turned off by default, but you can activate it.

Secure User Settings

There is a downside, which is that the WebFTP app won’t work. Personally? I find 99.999% of WebFTP apps to be total drek. They’re messy, kludgy, and there are some great free apps like Cyberduck which even let you connect with DreamObjects!

Now that you have the user, we want to move the domain. This is so easy, anyone can do it. Go into Panel, click on domains, click on edit for the domain. Go to “Users, Files, and Paths” and change the user in “Run this domain under the user:”

Changing Users

Really, it is that simple.

Why We Don’t Auto-Update Plugins

Since the push of DreamPress (which I’m totally digging), the ‘One Click Install’ feature of DreamHost has become a little more obvious to people, and it’s benefits and disadvantages.

What’s this auto-upgrade thing?

To make this simple, if you use DreamPress or our One-Click installer, we automatically upgrade WordPress for you! It doesn’t happen the very second WP has a new version, mind you, we spread it out to not destroy our servers, but you will get upgraded unless the upgrade feature was disabled (of course, you would never disable them, right?). Any time you want to see if you have automatic upgrades enabled, or want to run your own, head over to the DreamHost Panel.

Why not plugins and themes?

So why do we only do this for core WordPress? Because plugins and themes are messy.

Easy Update Button!

The safest upgrade in the world is the minor upgrade (like WP 3.6 to 3.6.1), as it’s exceptionally rare that it breaks anything. It’s not perfect, of course, sometimes we find out that a plugin or theme was doing something in a very non-optimal way before (if you hear ‘doing_it_wrong()’ please keep in mind that is not a value judgement, just a code comment, we all do it wrong in the beginning). But rarely will this kind of upgrade break your site.

Similarly, the major releases (3.5 to 3.6) are perhaps surprisingly stable. They’re tested, a lot. At DreamHost there are two people (me and Shredder) on the core contributor list, and we’re heavily involved in WordPress development every single day, at work and at home. We keep up with WP changes, test them on DreamHost, and work with the core team to resolve issues before they even release a beta! We’re on the job!

“But hang on!” I hear you say. “I upgraded to 3.6 and it broke my theme!”

And THAT is why we don’t upgrade themes.

I know, I know, it sounded counter-intuitive. You have to look at it a different way. Your theme stopped working with WordPress 3.6. That means something in the theme is not compatible with the best practices in WordPress core. Translation: WP didn’t break, your theme had a bug.

It sounds like semantics, or hair-splitting, and I totally get that. It also sounds like we’re passing the buck. We’re not! And we’re not trying to imply the theme (or plugin) developer who now has a broken product is a bad coder, or doesn’t pay attention to WordPress. What we mean is that themes and plugins, as they are used by much smaller segments of the WordPress community (everyone uses core, but maybe only 1000 use that theme), it just can’t be tested as robustly. This is especially true of the solo-developers. Speaking as one, I used to develop WP only in my free time, so any time WP had a new release coming up, I had to take days to test all my plugins, and pray I got everything. Invariably I missed stuff. It happens. We’re humans.

Breaking isn’t the only reason, though. Sometimes an upgrade is messy and complicated.  Take, for example, NextGEN Gallery. When version 2.0 came out, it inadvertently broke a lot of installs. There was chaos, drama, and finally an open letter. How did this happen? It happened because NextGEN is hella complex, and it’s used in myriad different ways. It happened because plugins and themes can do anything with WordPress.

Police_man_update.svg

Blindly updating core is safe. It’s tested and easy to roll back. Blindly updating themes and plugins are not always easy to roll back, they’re not always easy to upgrade (some require a massive upgrade script to run), and they may require you to make other changes in your theme. For that, we just don’t.

If DreamPress is MANAGED Hosting, like WordPress.com, how come THEY do it?

You mean why do the plugins on WordPress.com get auto-updated? Because you can’t install any plugins on WordPress.com! That’s all. They control everything, and simply activate various plugins depending on what package you buy. It’s not really the same thing at all, but I get why people think it is.

I don’t care! Can I auto-upgrade anyway?

Are you sure? Okay, then! Install the plugin Automatic Updater (by Gary P.) and set it to upgrade your themes and plugins. I personally use it on all my sites, but I’ve also personally vetted each and every plugin on my sites.

Upcoming Speaking Gigs for DreamHost and WordPress

header_logo

  • WordCamp San Francisco – July 26-29 (“Don’t Use WordPress Multisite”)
  • DreamCon – Aug 2-3 (“Choosing WordPress Plugins” and “Get Out Of The Monkey House”)
  • WordCamp Portland – Aug 10 (“Rolling Your WordPress Support Character (without any code)”)

You get me twice at DreamCon. Twice the elf for one low payment!

I believe all these will be recorded and made public.

Migrating to DreamPress

I should start with the note: You do not need to do this. We’re finishing up the last bells and whistles on a script that will handle all this for you if you have a One-Click-Install, but if you really just can’t wait or had a manual install, here’s what you’ll need to do. Keep in mind, there will be about an hour where your hosting will ‘vanish.’ In the words of Ford Prefect, don’t panic.

 

Again, you don’t have to do this. We will have a magic button soon enough. That’s why this isn’t going up on the Wiki, it’s really not going to be (long term) useful except to people who love experimentation.

We have a magic button!

magicbutton

But if you still want to do it manually, read on.

So you saw the news about DreamPress and read our bragging post about it? You got super super excited and then bummed, because the magic button isn’t done yet? Well… Okay, you can migrate manually (I did it for this site yesterday), but you need to know shell. You can do all this with FTP, but it’ll take way longer.

If you just want to make a new domain, read DreamHost Wiki: DreamPress, and you’re good to go! Otherwise, pull the hat down snugly, because here we go!

1. Remove Hosting

1-removehosting

Yes, I know. It’s scary. By removing hosting you will turn your site to DNS only. This is OKAY. Your files and your DB will remain exactly where they are. The Remove button is right under ‘Fully Hosted / User : elftest‘ so just click that.

2-see-DNSonly

See? Now it’s DNS only.

2. Add DreamPress hosting

Go to https://panel.dreamhost.com/index.cgi?tree=domain.wordpress& and add a new site.

3-addDP

You should see a happy green box telling you that it will take 15-30 minutes to provision you the site. Sorry about the wait time, but we’re actually building you the server stuff on the fly. It’s special.

4-success

While you’re waiting, let’s get some things done.

3. Export the old DB

Everything is perfectly safe and sound, so just go ahead and do that. Save it locally to your computer.

Go to https://panel.dreamhost.com/index.cgi?tree=goodies.mysql& and log in to your SQL database. The directions are the same as our normal Backup MySQL ones, so just go and do that.

If you’re Command Line savvy, you can do this via WP-CLI.

ssh oldaccount@oldserver.dreamhost.com
cd example.com
wp db export

That will reply with “Success: Exported to example_com.sql”

By the way, you’ll need to have the server name (not your domain name) in order to SSH in, as we’ve already pointed your domain to DreamPress. It’ll be something like ps10000 which makes your SSH ps10000.dreamhost.com. You can leave the SQL file there, we’ll pick it up later on in the show.

As soon as you get that email saying “Yay! DreamPress for you!” we’ll ignore the email’s directions and skip on to…

4. Get the new credentials for both SQL and SFTP.

On the DreamPress page, you’ll see your new site info.

5-newinfo

You’ll be able to find the new passwords at the usual locations. In the case of the user account (which will be something like wp_kxezav), you’ll want to set it to something you know. While you’re in there, change the account type to “Shell account – allows SFTP/FTP plus ssh access.” I personally also check to disallow FTP, for security. I also like to rename the account something like ‘ElfTest – DP’ so I know this account is for ElfTest on DreamPress.

By the way, you may wonder “Why can’t I have one ID for all my domains on DreamPress?” and the answer is twofold. First, we’re charging you per site. Yes, site. Secondly, security. If one account gets hacked, the others are safe. This is a good thing!

5. SSH into your new account

It’ll be ssh wp_kxezav@ps1121212.dreamhostps.com or such and this will dump you into not the domain, but the folder above it. This is important! You need to be in the example.com folder in order to do anything. Notice also how the domain is suddenly dreamhostps.com and not just dreamhost.com? Also important.

By the way, if you’re going to be using a lot of SSH, you should set up passwordless SSH access. It’s perfectly safe (in fact, safer than entering a password), and has to be set up per computer but .. how many of us use more than one computer? Hush, geeks.

6. Super power time! Let’s copy everything over!

Actually, let’s delete everything first. Yes, I know what I just said. There are reasons. This is just faster. I’m super lazy, so I first opened up wp-config.php and copied the SQL data for the NEW database.

// ** MySQL settings - You can get this info from your web host ** //
/** The name of the database for WordPress */
define('DB_NAME', 'example_com');

/** MySQL database username */
define('DB_USER', 'examplecom1');

/** MySQL database password */
define('DB_PASSWORD', 'likeaflaninthecupboard');

/** MySQL hostname */
define('DB_HOST', 'mysql-1.example.com');

Obviously changed for my protection. You’d never publicize your passwords. Right? RIGHT? Good. I saved this to a text file on my laptop for the time being. Now let’s delete:

ssh newuser@ps1121212.dreamhostps.com
cd example.com
rm -rf *

This wipes out everything in my domain’s folder. Make 100% absolute sure you got the right folder! Once you’ve done it, let’s copy things over!

scp -r olduser@oldserver.dreamhost.com:example.com/ .

SCP is ‘Secure Copy’, and is a fancy pants Unix Command. I’m fond of it. You’ll notice that I said to use ‘oldserver.dreamhost.com’ and not ‘example.com’ and this is because we’ve already pointed your domain to DreamPress. Zoing! When you do this, you’ll be prompted for a password.

Then you’ll get a mile of stuff like this:

wp-config.php                                                  100% 3583     3.5KB/s   00:01
xmlrpc.php                                                     100% 2719     2.7KB/s   00:00
readme.html                                                    100% 9177     9.0KB/s   00:00
admin-bar-sprite.png                                           100% 2470     2.4KB/s   00:00

This is SCP copying everything over, safe and sound.

7. Change your Database Stuff

There are two parts here. First you want to copy that DB stuff you saved before into the wp-config.php file, replacing the configuration you had there before. Second you want to import that backed up database into the new DB.

You can do this via phpMyAdmin if you want, but if you’re using wp-cli (and you should, it’s awesome), you can do this:

wp db import example_com.sql

Whaaaaat? How did that work? Remember when you exported on the old setup and then SCP’d the files over? Guess who came with! That’s right, you slipped your DB over nice and fast, and boom goes the dynamite, you’re in.

8. Have a beer!

I always end things with a celebratory something. Your URLs didn’t change, so you’ve got nothing to worry about. Once you’re sure everything’s good, go ahead and delete the old user ID as long as you are 100% certain you’re not still using it!!! Remember, a lot of us use the same IDs for multiple domains.

Kick PageSpeed Up A Notch

If you’re using Apache and PHP 5.3 on your DreamHost domain, you have the magical power to enable Google PageSpeed. Just go and edit your domain and make sure you check the box for “Page Speed Optimization”:

PageSpeed Option

But what does that even mean, I hear you ask?

partnersPageSpeed is Google’s way to speed up the web (yeah, that was redundant), and it serves as a way for your server to do the work of caching and compressing, taking the load off your webapps. Like WordPress. Anyone can install this on their apache server, and it’s free from Google Developers: PageSpeed Mod. Since you’re on DreamHost, you lucky ducky you, we did it for you. Now you can sit back and relax.

The first thing to notice when you turn on PageSpeed is that it minifies your webpage. That means it takes your pretty formatted source code and gets rid of the extra spaces you don’t use. This is called by using the PageSpeed filter “collapse_whitespace.” Another filter we use is “insert_ga” which is how we’re magically able to insert your Google Analytics for you from your panel. That filter automatically inserts your GA code on every page on your domain. That’s right! No more plugins!

If you’re like me, you may start to wonder what other filters you should use, and that entirely depend on what you want to remove. I knew I wanted to remove code comments like the following:

<!-- #site-navigation -->

That’s easy! There’s a filter for “remove_comments” so I can just use that. They have a whole mess of filters listed in the Filter Documentation and reading through it took a while. If you read each one, at the bottom they talk about how risky a certain filter is. Taking that into account, I went ahead and added some low and some high risk filters, since I know what I’m using.

The magic sauce to add all this is just to edit your .htaccess and put in the following near the top:

<IfModule pagespeed_module>
    ModPagespeed on
    ModPagespeedEnableFilters remove_comments,rewrite_javascript,rewrite_css,rewrite_images
    ModPagespeedEnableFilters elide_attributes,defer_javascript,move_css_to_head
    ModPagespeedJpegRecompressionQuality -1
</IfModule>

Really, that’s it.

The ones I picked are:

  • remove_comments – Remove HTML comments (low risk)
  • rewrite_javascript – minifies JS (med. to high risk, depending on your site)
  • rewrite_css – parses linked and inline CSS, rewrites the images found and minifies the CSS (med. risk)
  • rewrite_images – compresses and optomizes images (med. risk)
  • elide_attributes – removing attributes from tags (med. risk)
  • defer_javascript – combines JS and puts it at the end of your file (high risk AND experimental!)
  • move_css_to_head – combines CSS and moves it to the head of your file (low risk)

Now keep in mind, not all of the features will work. While DreamHost is on a pretty cutting edge version of PageSpeed, they’re constantly innovating over there and improving. The best thing about these changes is, if you do it right, you can speed your site up faster than any plugin could do for you. And that? Is pretty cool right there.

Subdomain vs Domain

When two words are very similar, it’s easy to get confused. Which witch is which? Whether, weather, and wether. Affect vs effect… Okay, you know, English sucks. We have way too many words that will drive you to drink, and if you know anyone who’s learned English as a second language, please take time to tell them how amazing they are. My father’s wife is Japanese, bilingual in French, and is learning English. I know a smattering of French. Our conversations are fantastically amusing and thankfully we have great senses of humor.

Because I’m that familiar with the crazy of my native language, I have no surprise that people get subdomains and domains confused. Here’s the basic statement:

A subdomain is not the same as a domain.

That’s it. But since I don’t expect everyone to know what the heck I just said, I’m going to explain. Remember, don’t think you’re stupid for not knowing this! You can’t magically know everything, you have to learn it, and there are people like me who want to help you. Where the confusion kicks in isn’t that we call it a ‘subdomain’ but that the official definition is “a subdomain is a domain that is part of a larger domain.” So we’ve just said a domain of a domain, and yet here I am pushing you and saying that a subdomain isn’t a domain when it clearly is.

It is and it isn’t.

  • A domain is pretty simple: elftest.net is a domain. It’s the solid basis that all websites are built on.
  • A subdomain is a subset of the domain: tools.elftest.net is a subdomain on elftest.net.

Notice how ‘tools.’ is in front of elftest.net? That extra period between tools and elftest is how we know this is a sub domain. The .net part is called the ‘Top Level Domain’ and any time you see www, that actually isn’t a subdomain, but a special term… You know what, let’s break this down with a picture.

Domain Example

You can ignore protocol for now (we can get into that another time). What we’re looking at is this:

URL: http://www.example.com/index.html
Top-level domain name: com
Second-level domain name: example.com
Host name: www.example.com OR example.com

Why is www special? It has to do with a lot of boring history, but suffice to say that used to be how we knew it was a webpage! Now we use http:// to say ‘This will be a webpage’ so many of us (myself included) feel that www is unnecessary and just makes URLs longer. However because of history, http://www.elftest.net and http://elftest.net will forever point you to the same place. This actually means that www is a subdomain, but it’s a very special one that points to the same place as no www at all. In very rare cases, a fancy website will redirect www and non-www to different places, but this is the exception, not the rule. Good SEO practices are to have the www and non-www point to the exact same place.

The meat of the matter is that most of the time, when someone asks ‘What’s your domain?’ they really mean ‘What’s your host name?’ My host name is elftest.net (or ipstenu.org or halfelf.org…. I have a lot of domains

Now let’s look at a subdomain.

Subdomain Example

They look shockingly similar, except that instead of www in front, I have sub. So what’s the deal here? Well because I’m using something other than www, I’ve designated sub.example.com as a subset of example.com, and thus a subdomain. Yes, it’s backwards. Sub should be below or behind, but remember, we’re calling .com the top level domain, so right-to-left this makes more sense.

I know. It’s all clear as mud. Even writing this I sat there and muttered “This stuff is nuts.” I know all this didn’t explain everything as clearly as I could wish, but I’ll break it down into the simplest terms that, while not 100% technically accurate, will tell every decent web tech what you mean:

When someone asks “What’s the subdomain?” you answer ‘sub.example.com’

If someone asks “What’s the domain?’ you say ‘example.com’ (sometimes they’ll ask “What’s the main domain?”)

If you’re on Multisite and someone asks “What’s the mapped domain, and what subdomain does it point to?” you say ‘mappeddomain.com and it points to mapped.example.com’

And never ever use domain mapping plugins for your subdomains. Those are for grownup domains only, not your subdomains.

For extra credit: Third level domains are what you get when you see things like example.co.uk – example isn’t a subdomain here, it’s the main domain. co.uk is the TLD. Why third? Well, we’d already used sub and second, and we needed some way to say that this is part of the primary URL, and not a subset. Also geeks love to confuse people.

Domain Registration, No Hosting

Just want to use DreamHost for DNS? You can do that!

Login into your Panel and go into Domain > Registrations.

Click the “Add Hosting” button on the far right.

It will redirect you to a new page and from that page you can select from “Fully Hosted, Redirect, etc”. The very last one is “DNS Only”.

Go ahead and select that and there you go!

You can also go to the Manage Domains page and click on (Add New Domain / Sub-Domain button), and scroll to the bottom of the next page to set it up for DNS Only.

I’ll be in Tybee!

There’s an upcoming WordPress Community Summit, and I’ll be attending! I was invited before I was employed here at DreamHost (who is providing lunch, yay!), so now I’m serving two purposes! The first is as a community support leader, and in that auspice, I plan to represent the common user. The second is as DreamHosts’s WordPress Support Manager, and there I will represent the support my company provides you DH users.

Do you have any topics you’d like to see me address at the meetup? Any annoying WordPress/DreamHost issues taht you’re not sure is WP or DH? Leave a comment and I’ll do my best!

Subdomains Back Where They Belong

In my last post, I talked about how I did something dumb with my subdomains.

How did I install subdomains?

Stupidly. Or rather, stupid for DreamHost. See, many other hosts, when you make a subdomain, come up with this structure for your files:

/home/ipstenu/public_html/
                         /subdomain1
                         /subdomain2
                         /addon.com

So when I made my subs, I made them similar to that. What DreamHost does is this:

/home/elftest/elftest.net/
             /db.elftest.net/
             /addon.com

I suggest you do the default! If you didn’t, however, there is a way to fix it. It’s a two step process.

1) Move the files.

I found it easier to do this in Unix $ mv elftest.net/trunk trunk.elftest.net (this moves and renames all in one). If you wanted to do it via FTP, just drag and drop, then rename.

2) Change the location in Panel.

Go into your panel, edit the domain, and change elftest.net/trunk:
before: elftest.net/trunk

To trunk.elftest.net:
after: trunk.elftest.net

Give it 5 to 10 minutes, and you’re done!

tl;dr to the whole thing is this: Trust the tool! (Sharon, that was for you!)

Is It My Server or My Theme?

This could go on any of my sites, but since the conversation started on the DreamHost forums, I thought I’d tackle it here.

When your site is running slow, it’s easy to pick on the webhost or the server you’re on, saying that’s the problem, and demanding someone else fix it. The truth is that speed involves a lot more variables than just the webhost. Sure, if your host is slow (or down), you’re stuck waiting on us, but there are a couple really easy ways to determine where the slowness is, and you might be surprised.

If you’re using a CMS like WordPress or Drupal, take a look at how long a page takes to load the first time, and then again on a refresh. When you look at these pages, they’re in PHP and take a little time to process. The more complex your code, the longer it can take to display. This won’t really impact a refresh, but it’s a good idea to see if your browser is caching anything. If the site is really slow, go look at a static HTML or TXT page. On WordPress, look at http://yourdomain.com/readme.html and see how fast that loads. If that’s slow, hey! It is your server! Open up a ticket with us and tell us that the site is slow to load static pages. It’s really important that you tell us what you’ve done, so we don’t have to waste time re-doing it all for you.

But most of the time you’ll see the html loads really fast. Why is that? It’s that pesky PHP taking a while to render. Now I know this brings up the obvious question of why would we use PHP if it takes longer to load, and the answer is complicated. There are a lot of benefits to using PHP (like being able to use those cool CMS’s to make publishing your site easier), and I’m not going to go into them. Just know that if you choose to use a modern CMS, then you’re likely going to be using PHP to render your site.

That means we have to consider how to make our PHP run faster. If you’re on shared hosting, the server side work should have been done for you, and if things are still slow then you have to consider the painful option that you did this to yourself. Don’t worry! That’s not a terrible thing, you probably just picked a theme, or a plugin, that is totally perfect for you, but a little slow. This is why people say ‘too many plugins/extensions slow your site.’ It’s not true, but the idea is that the wrong one will slow you down. And that is certainly true.

Go to Google PageSpeed Insights and check your site out. It should give you a hint as to what’s lacking. Don’t take this as the holy grail, though. Sometimes Google has really dumb advice, like ‘You should compress the code you’re using from google.com!’ Really? So why don’t you compress it, or tell me ‘Use this code instead from us! It’s already compressed!’ In theory, all of Google’s jquery code has a compressed version, but that’s not what most people see, so telling us to use it but not how is pretty idiotic, in my opinion.

I always tell people to look into minifying their output. That means you use a tool to make your HTML all mashed up together when someone looks at your source code. This simple step has amazing results for most sites. It took my Google Speed score from 71 to 81. Any score above 75 is a ‘good’ score from my experience (Microsoft gets a 77, after all, and while Google gets a 99, their main page is pretty minimalistic).

The point to all this is that your pagespeed is dependent on more than just how fast DreamHost is running. If you tell me that your site is slow, the first thing I do is look at a static page (I may even make one for you if I can’t find one). From there, maybe I’ll poke at the server, but most of the time it’s been your site’s configuration. I say this from a place of over 15 years of self-hosting: I’m nearly always the cause of my own problems.

Of course, if it’s your WordPress site being a slug, start with caching plugins and feel free to ask us for advice. If you have a wild and wooly, never been seen before, WP problem, don’t be surprised to see me showing up in your ticket.