The forums ran from 2008-2020 and are now closed and viewable here as an archive.

Home Forums Other Optimizing front-end code for large scale websites

  • This topic is empty.
Viewing 9 posts - 1 through 9 (of 9 total)
  • Author
  • #155171

    Hey all,

    I’ve been a front-end developer for some time now, and I consider myself pretty good. Problem is, that my experience has been largely freelance, so I don’t have much experience with large sites that have been around for awhile.

    I recently got a job as a the first front-end developer for a startup that has been around for 3 years. It’s a pretty huge site, and we have hundreds of thousands of users. So even small changes have a ripple effect that I’m not used to.

    It’s been a struggle getting used to this kind of system, and there’s all sorts of challenges.

    For example, our stylesheets are HUGE. Every time I want to make a change, I find all sorts of weird dependencies so everything becomes a bigger job. Not to mention that all the front-end code has been done by back-end developers up until this point, so it is FAR from organized and elegant code.

    One of the reasons they wanted to hire me, was to start making the site responsive. I’m working on making a specific project responsive, and to do so I thought it best to make a whole new template and stylesheet, independent of the others so I wouldn’t have to contend with all the existing CSS. And that works when we’re creating something new from scratch, but it’s more challenging when we get into the rest of the site and existing pages.

    I’d also like to clean up how the stylesheets are built and served. So we can limit the unused CSS per page. We use SASS/Compass.

    So, any advice you can offer towards any of my problems would be greatly appreciated. Also, if there any books or resources out there that you think would help, please pass them on. I love this job and the startup, and I’d really like to be able to make it kick ass.



    Read everything by Harry Roberts (

    Normalising designs for better quality CSS

    Architecting Scalable CSS


    Adding some more resources (this forum will eat your text if you have 3 or more links in your post)… anyways…


    It sounds like your startup does not use a version control system (e.g., git)?

    That would be a very necessary first step. You need to be able to work on those things that “break” at your leisure, and have the confidence of being able to restore everything whenever you need to.

    Second would be a development site, where you can do these experiments without the stress of working on a live site. (I would hope you have this already.)

    Third – and probably not what you want to hear: refactoring. The first actual coding work you need to do is to take what you have now, and rewrite it into something that is organized and comfortable to work with. The huge css files, for example, should be split into logical, working components so they’re easy to understand. (Moving them to a preprocessor (e.g., SASS) would probably be worthwhile also.) Basically, before you can start doing anything, you need to get “the big picture.”


    One of the reasons they wanted to hire me, was to start making the site responsive.

    This, depending on how site is built, will be pain in the ass.

    My suggestion would be to use Mobile-First and start fresh. But that would take some convincing. Stats and trends will be your go to argument here. I think the way mobile is exploding, Mobile-First should be assumed out of the box. Just my 2c.

    +@traq 100%


    To add to what I said earlier (and +1 to @Alen and @Melindrea), your initial refactoring may not even involve any new features – it might look exactly the same when you are done. (Particularly if you need to “start fresh,” as Alen says, but they don’t want you to change the existing look.) It might be best to literally reorganize and component-ize everything without making any changes to the output code at all.

    It’ll give you a way to understand how everything works, while also preparing it for the changes you’re going to be making. (If this is how you decide to do it, more power to you – but make sure your boss knows they won’t see any changes, on the surface, right away!)


    @traq We already use SVN, and have multiple dev sites. Each developer has their own branch and development server. We also already use SASS.

    The problem with refactoring, is that I didn’t write this code and don’t know where each piece is used. They coded it all very unsemantically, so it’s a hot mess. It’s over 10k lines of SASS (before its compiled). I’ve seen classnames like “lessBoldAndNotBig” and they have this really terrible system of margin and padding helper classes, like .mar10 or .mt15. Drives me nuts. The whole SASS file is all one-time use classes and overly generic class names. There’s also a ton of inline and internal stylesheets. I thought I was being hazed when I looked at it for the first time.


    @traq We already use SVN, and have multiple dev sites. Each developer has their own branch and development server. We also already use SASS.

    Awesome. At least you don’t have to convince them of that.


    lol, that’s fantasti …er, uh, I mean, sorry, that’s rough.

    In all seriousness, this makes “refactor-first-with-no-changes” all but a necessity. You won’t be able to make any of this better otherwise – in fact, it’s practically unavoidable that things would get worse, very quickly. You need to sort out the current mess before building new stuff on top of it.

    The fact that you didn’t write it, and don’t understand it, is another reason why such a refactoring could be beneficial.

    The only practical alternative is literally rebuilding from scratch. And I don’t know, maybe that would actually be the better route. You’d have to decide which would get better results in better time. Unfortunately, it’s a big undertaking, but that’s what they hired you for, right? Tell them what needs to be done!


    Tear out the css, start fresh.

    Grab the relevant parts from the old css as you go and update as necessary.

    It’s not ideal, but better in the long run for everyone.

Viewing 9 posts - 1 through 9 (of 9 total)
  • The forum ‘Other’ is closed to new topics and replies.